We are sending emails (using custom cron jobs) whenever host is down in Elasticsearch Uptime (Heartbeat). We have a need to send link to single monitor, whenever it is down. Not sure how to achieve this as each monitor url is getting dynamically constructed with some random ID at the end as sample below. A
i' am using below code snippet to encode monitor.id to new field so that i can use this field to construct URL dynamically through code but i' am getting some weird characters as shown in the below image:
Thanks for reaching out!
Could you tell us the versions you are using? (Kibana, Heartbeat, Elasticsearch)
And I want to confirm, to be sure I understand properly, the values you are setting for
decoded.monitor.name are similar to
**MTAuMC4xOC4xMDk=/, is that right? And those are the values that are showing up with weird characters at Kibana Discover?
Do you happen to have the list of the names you have used so far? (so we can test ourselves with those values, too)
Kibana, Heartbeat, Elasticsearch --> 8.4.1
I think iam using wrong processor which is decode_base64_field:. I want to restate my requirement @Alberto_Delgado
Here is one of the endpoint we are monitoring using Heartbeat and below is the configuration.
- type: icmp
schedule: '@every 5s'
It is showing as below in the Uptime
when i click on name i.e IN1PRDVDHCP01 it is redicting to the below URL...
This string MTAuMTA2LjEwLjIzNQ== is encoded value of IN1PRDVDHCP01. So how to generate thats encoded value programatically so that i construct the url outside elastic.
It seems what you'd need is to generate a base64 encoded (not decoded) value of
monitor.id, which is what Uptime UI is doing to generate links to the monitor overview. Those strange values you're seeing is most likely the result of decoding values that are not encoded previously.
Unfortunately, there's not easy way to generate a base64 encoded value from any of the beats. The closest thing you could get to is using script processors but btoa utils don't seem to be supported inside beats engine. Ingest pipelines are probably capable of generating them, but since we generally recommend against using ingest pipelines to edit heartbeat streams, it's a not a use case we are familiar with or plan to support in the future.
Generating base64 encoded strings should be fairly commonly supported by any language runtime, so you could do it outside the elastic stack if you're programmatically processing these documents.
Hope it helps!
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.