Missing data when using using fields and tags in uptime 7.3.0

[Dannyb (Danny Bird)]

I’ve added some tags to my heartbeat monitor:

fields:
Environment: test
SiteName: mysite

fields_under_root: true ( although this doesn't make any different to the issue)

Soon as I do this on the uptime board, the monitor status grid doesn’t show anything.. it just shows the status going from left to right. the pings over time works fine. The search text box just has “loading,….” In it.

I can find my documents in discovery searching against the new fields

If remove the fields, delete the heart indexes, fresh the kibana indexes, pray a little it eventually sorts itself

Also, if I add tags the search doesn’t work in the uptime search bar like the discovery tab does..

Works:
tags:api

doesn’t work
tags:api AND tags:dev

I’m I using it wrong?

Is there any reason guys didn’t just create normal dashboards like the rest of us have to instead of creating your own custom ones? I’ve just got the continue frustration and disappointment when trying to do anything in kibana dashboards. I love the stack, but just things always fall short.
thanks

[jkambic (Justin Kambic)]

Hey @Dannyb; the filter bar we have been using in the Uptime UI has actually been refactored. It's been an extensive re-engineering of that piece of the plugin, but it's already merged and we expect it to be released in the upcoming 7.5.0 release of the stack, barring any unforeseen issues.

Additionally, while AND is not supported by the current filter bar, you can use OR in this case (a query like tags:api OR tags:dev) if that would be helpful.

[Dannyb (Danny Bird)]

Hi @jkambic
thanks for the info on the filter side, but is there anything on the custom fields usage? will that be fixed in up and coming release. I need to decide whether to invest time elsewhere or hold on here.
thanks
danny

[jkambic (Justin Kambic)]

Hey @Dannyb - sorry I didn't address the custom fields in my first reply.

The short answer is, yes, you should be able to use custom fields for filtering in the upcoming 7.5.0 release.

Here's a current build running, I've configured a Heartbeat instance to attach the custom fields like below:

 fields:
  Environment: "test"
  SiteName: "site-name"

Here's the Overview page (you can see the earlier gap where I had documents without these fields defined no longer show up):

The only thing you'll still be missing in 7.5 is autocomplete for custom fields. Anything outside the default mapping won't be available yet, but I've created an issue in our planning repo to track the addition of that feature. If you'd like, you can contribute ideas to the discussion that would help make this page more useful to you there.

I need to decide whether to invest time elsewhere or hold on here

We're actively maintaining and developing features for this solution, so if there are things we can do better or problems you're having using the UI or Heartbeat itself I'd encourage you to file issues at GitHub - elastic/uptime: This project includes resources and general issue tracking for the Elastic Uptime solution.

Thanks again for your questions, I hope this has been helpful.

[Dannyb (Danny Bird)]

ok I'll contribute over at github. Do you know when 7.5 is due out roughly? 7.3 is just to brittle and easy to break, so it's not something we can use.

[jkambic (Justin Kambic)]

Hey @Dannyb - so I wanted to verify the issue you reported for 7.3 regarding the UI crashing when using custom fields, because that should be supported. I re-created a similar environment to last week's example using a 7.3 stack and didn't have any issues using or syntax like mentioned above.

You mentioned that you deleted your index as part of troubleshooting the issue; you may have walked into an issue with Beats ILM. This is a fairly common issue to encounter when debugging/setting up; it's often convenient to delete the heartbeat indices with something like curl -X DELETE 'heartbeat*'. It sounds like you may have left heartbeat running while doing this, which can break the app. To prevent this, stop heartbeat fully before deleting its indices, then restart it. We've already merged in better error reporting there, but the fundamental issue is a tricky one to resolve. There's more information here https://github.com/elastic/elasticsearch/issues/41699

It seems like you should be able to accomplish everything you need in 7.3 (aside from having to use the or workaround mentioned above), but if there's anything else happening to you that you feel makes 7.3 seem unstable, please file an issue with us so we can investigate.