- TypeScript 95.5%
- JavaScript 3.7%
- SCSS 0.5%
- ANTLR 0.2%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
* fix(slo): skip per-range drafts with more buckets than an SLI can carry The SLO route caps bucketBounds at 64, but Suggest copied a per-range histogram's full bound list into the draft, and the validator didn't check the length either. A histogram with more than 64 finite buckets got a draft that showed as creatable and was then rejected on create. - One shared MAX_BUCKET_BOUNDS (64) used by the route schema, the validator and Suggest. - Suggest skips such per-range drafts and lists them with a reason, the same way it handles thresholds the buckets can't measure. - The validator rejects more bounds than the limit, so the wizard reports it before the request. - slo_state.test.ts: the expected color/label maps now include source_idle and sli_uncomputable (they're Record<SloHealthState, ...>). Signed-off-by: Ashish Agrawal <ashisagr@amazon.com> * fix(slo): say "bucket bounds" in the Suggest skip reason shape.bounds holds only the finite le bounds, so 65 bounds is 66 buckets (+Inf is one more). Count them as bounds, like the validator's message for the same limit, and rename the i18n key to tooManyBucketBounds to match. Signed-off-by: Ashish Agrawal <ashisagr@amazon.com> --------- Signed-off-by: Ashish Agrawal <ashisagr@amazon.com> |
||
| .cypress | ||
| .github | ||
| .husky | ||
| common | ||
| docs/integrations | ||
| public | ||
| release-notes | ||
| server | ||
| test | ||
| .env | ||
| .gitignore | ||
| .lycheeignore | ||
| .whitesource | ||
| ADMINS.md | ||
| babel.config.js | ||
| CODE_OF_CONDUCT.md | ||
| codecov.yml | ||
| CONTRIBUTING.md | ||
| cypress.config.js | ||
| DEVELOPER_GUIDE.md | ||
| docker-compose.yml | ||
| Dockerfile | ||
| eslint.config.js | ||
| LICENSE | ||
| MAINTAINERS.md | ||
| NOTICE | ||
| opensearch-dashboards-plugin-helpers.dev.json | ||
| opensearch_dashboards.json | ||
| package.json | ||
| README.md | ||
| RELEASING.md | ||
| SECURITY.md | ||
| tsconfig.json | ||
| Using-Docker.md | ||
| yarn.lock | ||
- Observability
Observability
Observability is collection of plugins and applications that let you visualize data-driven events by using Piped Processing Language to explore, discover, and query data stored in OpenSearch.
Code Summary
Dashboards-Observability
| Test and build | |
| Link Checker | |
| Code coverage | |
| Distribution build tests |
Issues
Plugin Components
Trace Analytics
Trace Analytics page provides instant on dashboards in OpenSearch Dashboards for users to quickly analyze their logs. The plugin uses aggregated results from two indices, otel-v1-apm-span-* and otel-v1-apm-service-map* created by the otel-trace-raw-processor and service-map-processor, and renders three main views:
-
Dashboard: an overview of the trace groups and three charts: error rate, throughput, service map.
-
Traces: a table of top-level traces with unique trace id's, where users can click on any trace to see its end-to-end performance metrics, service performance metrics, and a span latency metrics in a Gantt chart.
-
Services: a table of the services, where users can click on a service to see its performance metrics and related services.
Additionally the fields can be sorted and filtered.
Event Analytics
Event Analytics allows user to monitor, correlate, analyze and visualize machine generated data through Piped Processing Language. It also enables the user to turn data-driven events into visualizations and save frequently used ones for quick access.
Metrics Analytics
Metrics Analytics allows ingesting and visualize metric data from log data aggregated within OpenSearch, allowing you to analyze and correlate data across logs, traces, and metrics. Previously, you could ingest and visualize only logs and traces from your monitored environments. Using Metrics Analytics one can observe your digital assets with more granularity, gain deeper insight into the health of your infrastructure, and better inform your root cause analysis.
Operational Panels
Operational panels provides the users to create and view different visualizations on ingested observability data, using Piped Processing Language queries. Use PPL 'where clauses' and datetime timespans to filter all visualizations in the panel.
Notebooks
Dashboards offer a solution for a few selected use cases, and are great tools if you’re focused on monitoring a known set of metrics over time. Notebooks enables contextual use of data with detailed explanations by allowing a user to combine saved visualizations, text, graphs and decorate data with other reference data sources.
Integrations
Integration is a new type of logical component that allows high level composition of multiple Dashboards / Applications / Queries and more. Integrations can be used to bring together all the metrics and logs from the infrastructure and gain insight into the unified system as a whole.
Integration usually consist of the following assets:
- dashboards & visualization
- schema configuration (mapping & templates)
- data on-boarding (sample data)
Please See additional information documentation
Integration Spec RFC
Observability Correlation
In order to be able to correlate information across different signal (represented in different indices) we introduced the notion of correlation into the schema. This information is represented explicitly in both the declarative schema file and the physical mapping file. Using this metadata information will enable the knowledge to be projected and allow for analytic engine to produce a join query that will take advantage of these relationships.
The Observability dashboard vision of telemetry Data Correlation
WIKI Home
Please see our WIKI page for additional information WIKI to learn more about our features.
Documentation
Please see our technical documentation to learn more about its features.
Contributing
- See developer guide and how to contribute to this project.
- See Integration Contribution Guide for integration creation additional context
Getting Help
If you find a bug, or have a feature request, please don't hesitate to open an issue in this repository.
For more information, see project website and documentation. If you need help and are unsure where to open an issue, try the Forum.
Code of Conduct
This project has adopted the Amazon Open Source Code of Conduct. For more information see the Code of Conduct FAQ, or contact opensource-codeofconduct@amazon.com with any additional questions or comments.
Security
If you discover a potential security issue in this project we ask that you notify AWS/Amazon Security via our vulnerability reporting page. Please do not create a public GitHub issue.
License
This project is licensed under the Apache v2.0 License.
Copyright
Copyright OpenSearch Contributors. See NOTICE for details.