Your data. Anywhere you go.

New Relic for iOS or Android


Download on the App Store    Android App on Google play


New Relic Insights App for iOS


Download on the App Store


Learn more

Close icon

How to exclude one of the servers from alert policy?


#1

Let’s say I have 1 APM and the agent is running on 3 different servers (same application). Is there a way to exclude one of the servers from alert policy? Looks like policy is attached to the application, not the server itself. Or, I guess a better question is - is there a way to associate alerts to the server, not the application? Thanks!


#2

Hi @isyndicate - It may be possible. What is the metric that you wish to alert on?


#3

ATM, I have two policies - error rate and phpfpm response time (via HttpDispatcher, this is for PHP application). I think when I raised the same question couple of years ago, at that time the only solution was to split into two applications, and have servers report to different ones - for example one for production, and another for staging (dev/qa/etc).


#4

Hi @isyndicate, just wondering if scoping your Alert to specific instances would apply to your use-case here? :slight_smile:


#5

I’d like to hear a little more about your use case @isyndicate. Are you actually monitoring a staging and production app or is this just two instances of the same app behind a LB? Or maybe something else? The way the New Relic rolls up instances, and the configuration options for monitoring them, reflect some of the philosophical ideas we have about the best way to configure and monitor things, whether those ideas were the motivation for how we built these systems or not. What I’m driving at is, “Do you actually want your staging and production instances to report to the same application? How is that improving your ability to learn about the performance of your application?” The more we know about how you’re using New Relic, and how you’ve configured your architecture, the better able we would be to try and help you come up with a solution that works for you.


#6

Thanks @parrott, I definitely see what you mean. So what I have is both Production and Staging use the same application in NR, where I can then check things specific to the instance (by switching the “server”). It seems like this is not how NR was meant to be used, where one would never mix production and non-production instances within the same application. This introduces few issues:

  1. I want all the settings to be exactly the same for both and don’t want duplicating things.
  2. I think it’s cleaner to have one application split by server/instance type vs having multiple applications of the same kind, but for each instance/server.

But if that’s the way to go, then not much of a choice here - we’ll have to duplicate our applications for each env type.


#7

I absolutely understand not wanting to have to duplicate things like settings for different apps/environments. The more things you have that you’re trying to keep in sync, the more chances you have to miss something. There are a few things I could suggest around, say, the agent config that might at least help the New Relic-y portion of this if you’re interested. We definitely go in for having different environments reporting to different apps around here. It can get challenging to keep things organized when you start having dozens (or hundreds) of things reporting to a single account and that’s one way we try and keep things from exploding. It’s much less of an issue when there are fewer things and I understand if it feels unwieldy to you.

Let me know if you’re curious about ideas for keeping stuff in sync!


#8

Gotcha, thanks for suggestions. Thankfully we don’t have too many applications so should not be that bad.


#9

Would naming the applications differently assist in your case @isyndicate? If your application is named “Funky service” in production, prefix the application name in config with “Staging - Funky service”. The applications can both run on the same server but error rates and response times can be set up as separate policies for each application or one policy with multiple conditions.


#10

Hey @isyndicate - was Stefan’s suggestion here helpful for you? let us know if you have further questions.