Definition: OpenSearch is the flexible, scalable, open-source way to build solutions for data-intensive applications. Explore, enrich, and visualize your data with built-in performance, developer-friendly tools, and powerful integrations for machine learning, data processing, and more.
Source: OpenSearch
eira:iopDimension: Behavioural IoP
LOST view: TVI-Member State Deployment Model
eira:iopSaliency: Container ABB is salient for technical interoperability because it provides the packaged software that contains or nurtures the functionalities of public services.
Identifier: http://data.europa.eu/dr8/OpenSearchApplicationService
eira:ID: http://data.europa.eu/dr8/OpenSearchApplicationService
ABB name: eira:ContainerSystemSoftware
EIRA concept: eira:ArchitectureBuildingBlock
Last modification: 2024/04/14
|
|
eira:ABB | eira:DigitalSolutionArchitectureDecisionGoal |
dct:modified | 2023-06-15 |
dct:identifier | ADR-20230515180947662 |
dct:title | Architecture Decision Record about Application of Service Monitoring Tools Configuration |
skos:example | Network Optimization:
Decision: The GitHub alertmanager receiver can easily be configured and operated to function with Prometheus alerts. It automatically creates issues in GitHub repositories for any active alerts being fired, making it visible for any user to track
All communication/updates/concerns related to the incident can be easily handled by adding comments in the issues created by the GitHub receiver
Unlike Option 1, there is no additional cost involved
There is no requirement for using JIRA/Slack for incident tracking, which are the only supported options in some of the tools listed in Option 2 (such as Dispatch and Response) In any case that such a requirement surfaces, we can use GitHub bots for different platforms such as GitHub for Slack and Google Chat to notify us of the issues immediately
It is actively being maintained and supported compared to some of the tools in Option 1 (such as Cabot and OpenDuty) which lack community support
Rationale: As we have multiple services/applications deployed and monitored in the Operate First environment (ex. Jupyterhub, Argo, Superset, Observatorium, Project Thoth, AICoE CI pipelines etc), we need to implement an incident reporting setup for handling outages/incidents related to these services. |
eira:adr_context | The context explains why we need to make a decision. It also describes the alternatives along with the pros and cons. |
eira:adr_decision | The decision describes the justification for why the particular solution was accepted. It has more emphasis on the why rather than the how. |
eira:adr_status | [Proposed (under review)|Accepted (approved and ready for implementation)|Superseded (superseded by another decision)] |
eira:adr_consecuences | The consequences section contains information about the overall impact of an architectural decision. Every decision has trade-offs. That’s why it’s crucial to include the analysis to provide a clear picture. |
eira:concept | eira:ArchitectureBuildingBlock |
eira:definitionSource | ISO/IEC/IEEE 42010:2022 |
eira:definitionSourceReference | https://www.iso.org/standard/74393.html |
skos:note | The Application of Service Monitoring Tools Configuration concept refers to the process of configuring service monitoring tools to ensure that they can effectively monitor and manage the performance of IT services. This involves setting up the tools to collect data on key performance indicators (KPIs) such as response time, availability, and throughput, and configuring alerts and notifications to ensure that IT teams are alerted to any issues that arise. The goal of this concept is to enable IT teams to proactively identify and address issues before they impact end-users, thereby improving the overall performance and reliability of IT services. |
eira:PURI | http://data.europa.eu/dr8/egovera/ApplicationOfServiceMonitoringToolsConfigurationGoal |
dct:type | egovera:ApplicationOfServiceMonitoringToolsConfigurationGoal |
skos:definition | Architecture Decision Record from where you should specialise the ADR SBBs regarding the Application of Service Monitoring Tools Configuration |
eira:view | Digital Solution Architecture Decisions Catalogue view |