cwielenb/CNCF-Dataset huggingface dataset:
Project: Promscale (Observability and Analysis / Observability)
File: PromscaleCompressionLow.md

Promscale contains high uncompressed data High disk usage by Promscale database Open Grafana and navigate to Promscale dashboard Go to Database section and see `Compressed chunks ratio`. If you see a ratio of < 10% then compression is not adequate in your system Open psql Check total number of chunks: `select count(*)::bigint from timescaledbcatalog.chunk where dropped=false and compressedchunkid is null;` Check total number of compressed chunks: `select count(*)::bigint from timescaledbcatalog.chunk where dropped=false and compressedchunkid is not null;` Check number of maintenance jobs: `select count(*) from timescaledbinformation.jobs where procname = 'executemaintenancejob'` Run the following debugging query: ```postgresql SELECT avg(chunkinterval) as avgchunkintervalnew_chunk, sum(totalsizebytes-coalesce(aftercompressionbytes,0)) AS notyetcompressed_bytes, avg(totalinterval-compressedinterval) AS avgnotyetcompressedinterval, avg(totalchunks-compressedchunks) AS avgnotyetcompressedchunks, sum(totalchunks-compressedchunks) AS totalnotyetcompressedchunks, count(*) total_metrics FROM prom_info.metric; ``` If `avgnotyetcompressedinterval > 2` then See for mitigation If `avgnotyetcompressedinterval is high and avgnotyetcompressedchunks is small (<2)` then it indicates very big chunks. This can lead to maintenance jobs stuck on compressing this large chunk or waiting for the current chunk to stop getting new data. See for mitigation Check number of databases: `SELECT count(*) from pgcatalog.pgdatabase` Check max number of background workers: `SELECT currentsetting(timescaledb.maxbackground_workers);` Make sure that max number of background workers > number of databases + 2. If not, see for mitigation Run: `SELECT * FROM timescaledbinformation.jobstats js INNER JOIN timescaledbinformation.jobs j ON (js.jobid = j.jobid) WHERE procname ='executemaintenancejob'` See Mitigation in for more info Note: When in addition to alert, if you have a alert firing, please solve the latter one first by following its runbook. Increase background jobs using: `SELECT promapi.configmaintenancejobs(numberjobs => <newjobscount>, newscheduleinterval => <newscheduleinterval>)` Increase background workers limit: Get current background workers limit: `SELECT currentsetting(timescaledb.maxbackground_workers);` Increment background workers limit: `ALTER system set timescaledb.maxbackgroundworkers to '<new workers limit>';` Reload postgres
Project: Elastic (Observability and Analysis / Observability)
File: floor.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Round a number down to the nearest integer. ``` ROW a=1.8 | EVAL a=FLOOR(a) ``` Note: This is a noop for `long` (including unsigned) and `integer`. For `double` this picks the closest `double` value to the integer similar to Math.floor.
Project: Litmus (Observability and Analysis / Chaos Engineering)
File: Jayadeep_KM.md

I'm , full stack developer and an open source enthusiast. I stumbled upon Litmus while I was working on a microservices hobby project. That was in October 2019, while Hacktoberfest was going on. Hence I got a chance to meet the community and contributors behind Litmus. The community really helped me to get started with Chaos engineering principles. The project I was working on had 4 microservices talking to each other. I wanted to make sure that the application can take care of error conditions such as Network delay, deletion of pods, unavailability of dependent services etc. and provide meaningful error messages instead of crashing. Based on manual testing all seemed fine, but chaos testing with Litmus revealed that some of the APIs didn't have the mechanism to deal with timeouts when trying to connect to other services. These valuable insights from Litmus helped me understand the flows in my design and forced to redesign the system using a different architecture. You can find the latest one here : .
Project: Netdata (Observability and Analysis / Observability)
File: megacli_bbu_relative_charge.md

This alert is related to the disk array controller's battery backup unit (BBU) relative state of charge. If you receive this alert, it means that the battery backup unit's charge is low, which may affect your RAID controller's performance or lead to data loss in case of a power failure. A low BBU relative charge indicates that the state of charge is low compared to its design capacity. The relative state of charge is a percentage indication of the full charge capacity compared to its designed capacity. If the relative charge is constantly low, it may suggest that the battery is worn out and needs replacement. Gather information about your battery units for all controllers: ``` sudo megacli -AdpBbuCmd -GetBbuStatus -aALL ``` This command will provide you with detailed information about the BBU status for each controller. Perform a manual battery calibration (learning cycle) on the battery with a low relative charge: ``` sudo megacli -AdpBbuCmd -BbuLearn -aX ``` Replace `X` with the controller's number. Please consult the , section 7.14, before performing this action. A learning cycle discharges and recharges the battery, which can help recalibrate the battery and improve its relative state of charge. However, it may temporarily disable the write cache during this process. Monitor the BBU relative charge after the learning cycle. If the relative charge remains low, consider replacing the battery in question. Consult your hardware vendor's documentation for guidance on replacing the BBU. Note: Data is priceless. Before you perform any action, make sure that you have taken any necessary backup steps. Netdata is not liable for any loss or corruption of any data, database, or software.
Project: Logging Operator (Kube Logging) (Observability and Analysis / Observability)
File: sumologic.md

title: SumoLogic weight: 200 generated_file: true This plugin has been designed to output logs or metrics to SumoLogic via a HTTP collector endpoint For details, see . ``` export URL='https://endpoint1.collection.eu.sumologic.com/receiver/v1/http/' kubectl create secret generic sumo-output --from-literal "endpoint=$URL" ``` ```yaml apiVersion: logging.banzaicloud.io/v1beta1 kind: ClusterOutput metadata: name: sumo-output spec: sumologic: buffer: flush_interval: 10s flush_mode: interval compress: true endpoint: valueFrom: secretKeyRef: key: endpoint name: sumo-output source_name: test1 ``` Add timestamp (or timestamp_key) field to logs before sending to SumoLogic Default: true Compress payload Default: false Encoding method of compression (either gzip or deflate) Default: gzip Dimensions string (eg "cluster=payment, service=credit_card") which is going to be added to every metric record. Comma-separated key=value list of fields to apply to every log. The type of data that will be sent to Sumo Logic, either logs or metrics Default: logs Delimiter Default: . Option to disable cookies on the HTTP Client. Default: false SumoLogic HTTP Collector URL Format to post logs into Sumo. Default: json Used to specify the key when merging json or sending logs in text format Default: message The format of metrics you will be sending, either graphite or carbon2 or prometheus Default: graphite Set timeout seconds to wait until connection is opened. Default: 60 Add the uri of the proxy environment if present. The threshold for chunk flush performance check. Parameter type is float, not time, default: 20.0 (seconds) If chunk flush takes longer time than this threshold, fluentd logs warning message and increases metric fluentdoutputstatusslowflush_count. Set _sourceCategory metadata field within SumoLogic Default: nil Set _sourceHost metadata field within SumoLogic Default: nil Set sourceName metadata field within SumoLogic - overrides sourcename_key (default is nil) Set as source::pathkey's value so that the sourcename can be extracted from Fluentd's buffer Default: source_name Name of sumo client which is send as X-Sumo-Client header Default: fluentd-output Field name when add_timestamp is on Default: timestamp Verify ssl certificate. Default: true
Project: Checkmk (Observability and Analysis / Observability)
File: 16239.md

key | value | compatible | yes version | 2.4.0b1 date | 2024-02-28T12:37:31+00:00 level | 1 class | fix component | checks edition | cre This werk affects you, in case you try to monitor your APC Rack Automatic Transfer Switch with <tt>apcatsstatus</tt>. Previously some devices were not discovered due to a too strict scan function. Futher, we enable monitoring other power supplies available at such devices as for example 1V and 3.3V. This was fixed now.
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-9-0-5.md

aliases: [] hide_menu: true labels: products: cloud enterprise oss title: Release notes for Grafana 9.0.5 <!-- Auto generated by update changelog github action --> Access control: Show dashboard settings to users who can edit dashboard. , Alerting: Allow the webhook notifier to support a custom Authorization header. , Chore: Upgrade to Go version 1.17.12. , Plugins: Add signature wildcard globbing for dedicated private plugin type. , Prometheus: Don't show errors from unsuccessful API checks like rules or exemplar checks. , Access control: Allow organisation admins to add existing users to org (#51668). , Alerting: Fix alert panel instance-based rules filtering. , Apps: Fixes navigation between different app plugin pages. , Cloudwatch: Upgrade grafana-aws-sdk to fix auth issue with secret keys. , Grafana/toolkit: Fix incorrect image and font generation for plugin builds. , Loki: Fix `show context` not working in some occasions. , RBAC: Fix permissions on dashboards and folders created by anonymous users. ,
Project: Pixie (Observability and Analysis / Observability)
File: guided_template.md

<!-- Thanks for sending a pull request! Here are some tips for you: If this is your first time, please read our contributor guidelines: https://github.com/pixie-io/pixie/blob/main/CONTRIBUTING.md and https://github.com/pixie-io/pixie/blob/main/DEVELOPMENT.md. Also, please delete all the comment blocks to make it easier for the maintainers to compose the final error message from this doc. All the fields need to be filled out inline. For example: Summary: Here is a description of this change, and it's allowed to span multiple lines. Leave an empty line between each block. --> Summary: <!-- Please include a summary of the changes and the related issue. Please also include relevant motivation and context. List any dependencies that are required for this change. --> Relevant Issues: <!-- Please list all the relevant issues (#<issue number>): eg. #1, #2. If the PR fixes an issue use `Fixes #<issue number>` --> Type of change: <!-- Add one of the following kinds: /kind bug /kind cleanup /kind documentation /kind feature Each type must include the entire "/kind {type}" text and not just the label. Optionally add one or more of the following kinds if applicable: /kind api-change /kind deprecation /kind failing-test /kind flake /kind regression --> Test Plan: <!-- For stylistic change that don't require tests or enhancements write: N/A. --> Changelog Message: <!-- Does this PR include user facing changes? If no, just delete this entire block. If yes, a release note is required: Enter your extended release note in the format shown below. If the PR requires additional action from users switching to the new release, include the string "action required". ```release-note Add your notes in this format, including the triple ticks. ``` --> Additional documentation: <!-- This section can be removed if this PR does not include changes to our public documentation. When adding links which point to resources within git repositories (px-docs, etc), please reference a specific commit and avoid linking directly to the master branch. This ensures that links reference a specific point in time, rather than a document that may change over time. See here for guidance on getting permanent links to files: https://help.github.com/en/articles/getting-permanent-links-to-files Please use the following format for linking documentation: ```docs [px/docs]: <link> [px/website]: <link> ``` -->
Project: OpenTelemetry (Observability and Analysis / Observability)
File: areas-of-interest.md

OpenTelemetry technical committee members, maintainers, and approvers may list their areas of interest below, to help the community to find good points of contact for topics of interest across the project. Technical committee members are required to list these areas of interest, and this is optional for maintainers and approvers. These listings may be useful to find an appropriate person to tag on an issue, for example. Members who are specifically employed by a company to contribute to the OpenTelemetry project are recommended to list their company affiliation, so that they may be contacted with vendor-specific concerns. <!-- Re-generate TOC with `markdown-toc --no-first-h1 -i` --> <!-- toc --> <!-- tocstop --> Trace API and SDK Semantic conventions OpenTelemetry protocol OpenTelemetry collector Metrics API and SDK Trace API and SDK OpenTracing compatibility Semantic conventions Metrics API and SDK Logging API and SDK SDK configuration OpenTelemetry Java OpenTelemetry protocol Metrics API and SDK and data model Metrics collection infrastructure Metrics protocol compatibility OpenTelemetry protocol Trace sampling algorithms Trace API & SDK Metrics API and SDK OpenTelemetry Protocol Telemetry correlation (Trace <-> Metrics <-> Logs via Resource, Exemplars, etc.) Protocol compatibility (OpenCensus, Prometheus, Statsd, etc.) Semantic conventions Logging API and SDK Metrics API and SDK Trace API and SDK OpenTelemetry .NET OpenTelemetry C++ W3C trace context specification OpenTelemetry protocol OpenTelemetry schemas and versioning Logging API and SDK Entities OpAMP Trace API and SDK Jaeger tracing compatibility OpenTracing compatibility W3C trace context specification Maintainers and approvers are invited to list their areas of interest to further assist the community in finding appropriate points of contact. OpenTelemetry Collector OpenTelemetry Python SDK configuration OpenTelemetry JavaScript W3C Trace Context Specification Trace and Metrics Trace Sampling OpenTelemetry collector Log data model Traditional log ingestion Telemetry processing OpenTelemetry Collector Distributed tracing Security Sampling Logging API and SDK Trace API and SDK OpenTelemetry C++ OpenTelemetry Protocol <!-- ### , Your Company -->
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: appdynamics.md

title: AppDynamics Integration sidebar_label: AppDynamics hide_title: true You can integrate Flagsmith with AppDynamics. This integration is helpful if you are self hosting and wanting to analyse the performance of Flagsmith in more detail. :::note AppDynamics is an Enterprise-only integration. ::: The application supports the use of AppDynamics for monitoring purposes. In order to setup AppDynamics for your environment follow the steps below: Set up your application in your AppDynamics dashboard using the "Getting Started Wizard - Python". In the wizard you will need to select the "uWSGI with Emperor: Module Directive" when choosing a deployment method On completing the wizard you will be provided with a configuration file named something like `appdynamics.template.cfg` provided, except with your application information. Make a copy of this information a place it in a file at the root of this repository called `appdynamics.cfg`. Note: there is a bug in the AppDynamics wizard that sets the value `ssl = (on)` which needs to be changed to `ssl = on` When running with the `docker-compose.yml` file provided ensure the `APP_DYNAMICS` argument is set to `on` as seen below: ```yaml api: build: context: . dockerfile: docker/Dockerfile args: APP_DYNAMICS: 'on' ``` Running the command below will build the docker image with all the AppDynamics config included ```bash docker-compose -f docker-compose.yml build ``` This image can then be run locally using the docker-compose `up` command as seen below ```bash docker-compose -f docker-compose.yml up ``` If you need additional AppDynamics setup options you can find the other environment variables you can set .
Project: Checkmk (Observability and Analysis / Observability)
File: 15332.md

key | value | date | 2024-04-16T13:09:47+00:00 version | 2.4.0b1 class | feature edition | cre component | inv level | 1 compatible | yes This element is already available for Linux, now the windows agent also supports reading this value. You have to update `mk_inventory.vbs` on the monitored host, to provide the necessary data.
Project: Vector (Observability and Analysis / Observability)
File: 2021-11-18-csv-enrichment.md

date: "2021-11-18" title: "Enrich your observability data from a CSV" description: "A guide to using the new CSV enrichment feature" authors: ["barieom", "lucperkins"] pr_numbers: [9069] release: "0.18.0" hideonrelease_notes: false badges: type: new feature We're excited to share that we've released a new feature that enables users to enrich events flowing through the topology using a CSV file. [Enrichment tables] are a new concept in Vector that enables you to enrich events from external data sources. To start, we've added the ability to enrich events from a CSV file by looking up a row, or rows, matching provided conditions, allowing users to map the data into the event using the full power of VRL. To support mapping events based on enrichment table data, two new VRL functions are now available: works by looking up a single row CSV file can return multiple rows in an array format for more complex use cases For example, when collecting events from IoT devices, you may want to keep your payloads coming from the devices to be small. By enriching events from a CSV file, users can reformat the data to be more human readable and provide better context (e.g., converting data emitted by the IoT device `1`, `2`, `3` to `"Low battery"`, `"Medium battery"`, `"High battery"`). Let's stick with the IoT example from above, and let's assume that our CSV file contains the below: ```csv code,message 1,"device battery full" 2,"device battery good" 3,"device battery ok" 4,"device battery low" 5,"device battery critical" ``` In order to use the csv file (let's call it `iot_remap.csv`), the following Vector configuration is required: ``` toml [enrichmenttables.iotremap] type = "file" [enrichmenttables.iotremap.file] path = "/etc/vector/iot_remap.csv" encoding = { type = "csv" } [enrichmenttables.iotremap.schema] code = "integer" message = "string" ``` Now, to translate the output from IoT devices to human-readable messages in our `iot_remap.csv` we can make use of the function: ``` toml [transforms.enrichiotlogs] type = "remap" inputs = ["vector_agents"] source = ''' . = parse_json!(.message) code = del(.code) row = getenrichmenttablerecord!("iotremap", { "code": code }) .message = row.message ''' ``` For our next steps, we'll look to add support for `or` conditions and add additional enrichment table types (e.g., reading from Redis), but if you any feedback in the meantime, let us know on our [Discord chat] or [Twitter].
Project: Grafana Tempo (Observability and Analysis / Observability)
File: instrumentation.md

title: Instrument for distributed tracing menuTitle: Instrument for tracing description: Client instrumentation is the first building block to a functioning distributed tracing visualization pipeline. aliases: /docs/tempo/latest/guides/instrumentation/ weight: 200 Client instrumentation is the first building block to a functioning distributed tracing visualization pipeline. Client instrumentation is the process of adding instrumentation points in the application that create and offload spans. Check out these resources for help instrumenting tracing with your favorite languages. Most of these guides include complete end-to-end examples with Grafana, Loki, Mimir, and Tempo. Most of the popular client instrumentation frameworks have SDKs in the most commonly used programming languages. You should pick one according to your application needs. OpenTelemetry has the most active development in the community and may be a better long-term choice. (deprecated) A collection of tools, APIs, and SDKs, helps engineers instrument, generate, collect, and export telemetry data such as metrics, logs, and traces, to analyze software performance and behavior. OpenTelemetry provides auto-instrumentation agents and libraries of Java, .Net, Python, Go, and JavaScript applications, among others. For more information, refer for the . These libraries capture telemetry information from a client application with minimal manual instrumentation of the codebase. * and {{< admonition type="note" >}} Jaegar client libraries have been deprecated. For more information, refer to the . Jaegar now recommends using OpenTelemetry SDKs. {{% /admonition %}} The Grafana blog periodically features instrumentation posts.
Project: HertzBeat (Observability and Analysis / Observability)
File: spring_gateway.md

id: spring_gateway Title: Monitoring Spring Gateway sidebar_label: Spring Gateway keywords: [open source monitoring tool, open source spring gateway monitoring tool, monitoring spring gateway metrics] Collect and monitor the general performance metrics exposed by the SpringBoot actuator. If you want to monitor information in 'Spring Gateway' with this monitoring type, you need to integrate your SpringBoot application and enable the SpringBoot Actuator. 1Add POM .XML dependencies: ```xml <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-actuator</artifactId> </dependency> ``` Modify the YML configuration exposure metric interface: ```yaml management: endpoint: gateway: enabled: true # default value endpoints: web: exposure: include: '*' enabled-by-default: on ``` | Parameter name | Parameter Help describes the | | || | Monitor Host | THE MONITORED PEER IPV4, IPV6 OR DOMAIN NAME. Note that there are no protocol headers (eg: https://, http://). | | Monitoring Name | A name that identifies this monitoring that needs to be unique. | | Port | The default port provided by the database is 8080. | | Enable HTTPS | Whether to access the website through HTTPS, please note that when HTTPS is enabled, the default port needs to be changed to 443 | | The acquisition interval is | Monitor the periodic data acquisition interval, in seconds, and the minimum interval that can be set is 30 seconds | | Whether to probe the | Whether to check the availability of the monitoring before adding a monitoring is successful, and the new modification operation | will continue only if the probe is successful | Description Comment | For more information identifying and describing the remarks for this monitoring, users can remark the information here | | Metric Name | metric unit | Metrics help describe | | | -- |--| | status | None | Service health: UP, Down | | Metric Name | metric unit | Metrics help describe | || -- |-| | profile | None | The application runs profile: prod, dev, test | | port | None | Apply the exposed port | | os | None | Run the operating system | | os_arch | None | Run the operating system architecture | | jdk_vendor | None | jdk vendor | | jvm_version | None | jvm version | | Metric Name | metric unit | Metrics help describe | | - ||--| | state | None | Thread status | | number | None | This thread state corresponds to | number of threads | Metric Name | metric unit | Metrics help describe | |||| | space | None | Memory space name | | mem_used | MB | This space occupies a memory size of | | Metric Name | metric unit | Metrics help describe | |-|-|--| | route_id | None | Route id | | predicate | None | This is a routing matching rule | | uri | None | This is a service resource identifier| | order | None | The priority of this route |