Forum Discussion

Chris_Gralike's avatar
Chris_Gralike
8 years ago

Configurable sender address

Hi,

Currently we are servicing multiple customers though LM and want to expand this service to more customers.

In this ambition we face one huge challange.

Our ITSM contains mission critical and detailed information on our customer systems. Because of this we are not allowed (and not willing) to open this system up for the internet and enable for LM HTTP integrations. This means we can only use email as a save interface between LM monitored systems and our ITSM. Mission critical systems are monitored by on-premise monitoring and notify us using unique sender adresses. This allows us to automatically differentiate between various customers and group/organize tickets accordingly.  Sadly all notification send by LM have a fixed sender adress. Because the same sender adress is used for all customer notifications, our ITSM tooling isnt able to differentiate between various customers. All notifications are reported from: alerter@#CUSTOMER#.logicmonitor.com.

Therefore we would like to request the ability to differentiate sender adresses from the escalation chain level. For example customer1.alerter@#CUSTOMER#.logicmonitor.com. customer2.alerter@#CUSTOMER#.logicmonitor.com. This additional field should be easy enough to filter out concerning actionable emails regex: ^.*alerter@(.+)\..+$ but will allow us to differentiate these tickets to various customer groups. This will then enable us to report about these notifications in our SLA reports accordingly, assign them to the right systems automatically, assign them to the right engineers automatically....... making our lives much easier ;-)

I really hope this can be addressed quickly.

sidenote: SSO might also be called a welcome feature, now i hold three accounts ;-)

notifications
  • mnagel's avatar
    mnagel
    Icon for Professor rankProfessor
    8 years ago

    The way I am using integrations to produce better alerts from LM would solve this problem as well.  The general strategy I have settled on is to submit all the tokens via email into our helpdesk (this has caused issues because the tokens available are not actually the best tokens for certain requirements, which I am still struggling with).  The raw input is processed by a template system, into which all the tokens are available as template variables, and the layout driver produces the desired output.  A procmail recipe filters the original message into a properly formatted final message with context-sensitive data added, conditional formatting, etc., and that is routed into the helpdesk.  The alertid value is used to keep related messages in the same incident.

    I can influence behavior of the helpdesk (RT in our case) via instructions in headers (stripped from the raw input to avoid security problems), so an alertstatus of "clear" will trigger a ticket autoclose, for example.  By including suitable properties, the behavior you describe could be achieved via properties set within each customer top-level (also sent via the raw token list in the integration definition) -- you would simply override the From address in your headers template based on the customer-specific properties.  So far, the results have been quite promising, but I am still in the early phase of development.  Something like this could potentially work for you, but I imagine the integration method would be significantly different.

     

    Regards,

    Mark

     

  • Anonymous's avatar
    Anonymous
    8 years ago

    Hi Chris, 

    Just to clarify, are you using a custom email delivery integration for your current alert delivery? I could see doing something like "api.alerter+##group##@##company##.logicmonitor.com", if you have your customers set up by group. Would something like that work for your use case?

    Clay

  • Chris_Gralike's avatar
    Chris_Gralike
    8 years ago

    Hi Clay,

    I wasnt able to alter the sender adress in the intergration myself, but your suggestion looks like it will work fine for our situation.

    Implementing it there might be a burden for some customers if this means its an 'allways on / off' kinda setting.

  • Chris_Gralike's avatar
    Chris_Gralike
    8 years ago

    In addition:

    Implementing it on the esclation chains level looks the best option to me.
    This will enable LM customers to do all kind of neat things and at a much finer grained configuration level.

    Differentiation we use with on-premise monitoring:

    1. 1. Differentiate on DTAP where P is escalated emediatly.  cust.prod@tld.ext; cust.dev@tld.ext;
    2. 2. Differentiate between stakeholder groups within customer environments assigning different requester groups. cust.infra@tld.ext; cust.app@tld.ext;
    3. 3. Differentiate between customers as discussed above.
      4. Differentiate between vendor groups implementing automatic routing by assigning different actor groups. cust.aix@tld.ext; cust.lux@tld.ext;

    again, being able to differentiate on a basic level would already be a huge improvement for us.