# Ingesting alarm lists from an external system

**URL:** <https://discuss.elastic.co/t/ingesting-alarm-lists-from-an-external-system/391225>\
**Category:** Elastic Observability\
**Created:** [October 27, 2026, 11:31am UTC](https://discuss.elastic.co/t/ingesting-alarm-lists-from-an-external-system/391225 "2026-10-27T11:31:21Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![RavuAlHemio](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/ravualhemio/32/148473_2.png) [@RavuAlHemio](https://discuss.elastic.co/u/RavuAlHemio)\
**Post date:** [October 27, 2026, 11:31am UTC](https://discuss.elastic.co/t/ingesting-alarm-lists-from-an-external-system/391225/1 "2026-10-27T11:31:21Z")

</div>

Greetings,

we are currently centralizing our logging and monitoring infrastructure around a central ELK stack. Processing log messages has been a breeze, of course, and we have also had a quick primer on how to tackle time-series data, but there's a third flavor of information that we would like to ingest: alert lists.

We have a few vendor-specific non-ELK systems that present a list of alarms; items disappear from this list when they are resolved. Our goal is to have the ELK stack collect and present such a list of issues, combining multiple sources:

- alerts derived within the ELK stack from log messages ("login attempt on switch SW321 at 4am")
- alerts derived within the ELK stack from time series data ("switch SW321 port 46 has been communicating with \>75% of its link data rate over the last 5min")
- alerts ingested from external alerting systems ("optical networking management system says multiplexer OM765 port 12 is down")

These external systems support access via a REST API with, conceptually, the following endpoints:

- `/alerts`: list of IDs of currently active alerts
- `/alerts/<id>` details for the alert with the given ID

As I understand it, the ELK stack is built more around events ("at 12:34pm, the connection on switch SW321 port 46 went down") than state ("the connection on switch SW321 port 46 is currently down"), which raises the question of how best to ingest such alert lists. Is there a structure that the community agrees on?

Thanks in advance and kind regards!

---

<div class="post-metadata">

**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\
**Post date:** [October 28, 2026, 11:25am UTC](https://discuss.elastic.co/t/ingesting-alarm-lists-from-an-external-system/391225/2 "2026-10-28T11:25:24Z")

</div>

Welcome to the forum. You ask an interesting question.

> [@RavuAlHemio](#):
>
> alerts ingested from external alerting systems

Maybe be specific on these "external alerting systems", and it's possible there is some integration, or someone reading the thread with specific experience on those precise systems and how they were integrated. In particular how the correct and current state of an (external) alert is maintained.