Am I able to use fieldnames as variables in webhooks?

Comments

7 comments

  • Official comment
    Avatar
    Nick Wilson

    Hi Jan & Jas,

    This is actually a feature that our team is working on now and should be available soon. Please see this feature request for more information: https://ideas.sumologic.com/ideas/SL-I-1856.

    If I've misunderstood your request, or you have any other questions please let me know.

    Thanks,
    Nick Wilson
    Customer Success Manager, Sumo Logic

    Comment actions Permalink
  • Avatar
    Mario Sanchez
    Jas,Although you cannot specifically call out the field names, you can include the results of your scheduled search into the webhook alert:http://help.sumologic.com/Manage/Connections_and_Integrations/Webhook_Connections/About_Webhook_Connections#For_Scheduled_Searches_(Logs)_Only Cheers,Mario
    0
    Comment actions Permalink
  • Avatar
    Jan Deelstra

    For example, it means my pager duty now has a description like this: `[{"ident":"sudo","message":"pam_unix(sudo:auth): authentication failure; logname=....` while my query in sumologic returns: `Failed sudo from: 'user' on 'hostname'`. (I could live with `[{"error": "Failed sudo from: 'user' on 'hostname'"}]`.

    Basically this means that every time we get paged from pagerduty, we need to go into sumologic to check what exactly is going on. 

    Only way to fix this is to build some intermediate service that parses what is being returned?

     

    0
    Comment actions Permalink
  • Avatar
    Paul Hirschorn

    Jan - we're facing the same issue and we're trying to work it out as well.   

    One option with PagerDuty is to use the custom event transforms, these are only compatible with the V1 Event API (https://v2.developer.pagerduty.com/docs/creating-an-integration-inline) You can write your own handler in javascript and fix the fields to your liking.  

    If you only want to see certain data and you're sort of ok with the format of `[{"error": "Failed sudo from: 'user' on 'hostname'"}]`.

    It's a bit more work but you can play with the fields as well to customize your errors, concat or format a few fields (https://help.sumologic.com/Search/Search-Query-Language/Search-Operators/concat / https://help.sumologic.com/Search/Search-Query-Language/Search-Operators/format)  and remove all fields except your concat field.  (https://help.sumologic.com/Search/Search-Query-Language/Search-Operators/fields)

    Granted, this is quite a bit of work it does get you to where you're trying to be.  

     

     

     

    1
    Comment actions Permalink
  • Avatar
    Nick Wilson

    Hi Paul,

    I just want to make sure you saw my reply above which cited this enhancement request which is currently in beta: https://ideas.sumologic.com/ideas/SL-I-1856

    I believe one of our product managers is still looking for customers to beta test this feature. You can email him directly to request to be added and discuss the functionality further. Look for his post on that page including his email address.

    If I misunderstood your requirements please feel free to reply back and let me know.

    Thanks,
    Nick
    Customer Success, Sumo Logic

    0
    Comment actions Permalink
  • Avatar
    Perry Ogwuche

    Hi Nick Wilson, was this feature ever released? It seems like I am able to send certain fields from my search result as payload variables (specifically to Pager Duty). However, when I try to parse certain fields from my search result so I can do something like: {{Result.field_name}} in my payload, it doesn't seem to work quite well.

    Specifically, the issue I am having is this:

    I am trying to access a nested Results field in Sumo and have it sent as part of my payload via a Webhook to Pager Duty. 

    In Sumo, as part of the Result of a search, I have a message field, _sourceName field etc which I can easily access by doing Results.message or Results._sourceName.

    However, when I have something like this as part of Result

    error: {
    code: 123,
    meta: { id: 112 }
    }

    I am not able to do Results.error.code

    I modified the search to copy the desired fields into new fields that have a field name with no dots. e.g. parse field=%"error.code" as error_code, so I can do something like: {{Results.error_code}} in my payload but for some reason that doesn't work consistently. 

    It doesn't work when my search looks something like this:

    | json auto
    | parse field=%"error.code" "*" as error_code nodrop

    But works when I have something like:

    | json "error.code" as  error_code, nodrop

    Seems like it doesn't like when I combine the use of json auto and try to parse individual fields. 

    I hope this makes sense. Any suggestion for this?

    0
    Comment actions Permalink
  • Avatar
    Rick Jury

    HI Perry,

    this was released in Dec 2019 - the docs page for this feature says:

    "A field name must exactly match the field from your search and must be all lowercase alphanumeric characters, underscores, and spaces."

    This means nested json values with . in them will not work.

    Your last example is the correct way to solve this problem - and given its much more efficient than json auto (which effectively parses every json field out in a search), it's what I would recommend as the best way to write a scheduled search. This is also a better query as you are renaming the field in one single step, not parsing twice.

    | json "error.code" as error_code nodrop
    1
    Comment actions Permalink

Please sign in to leave a comment.