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

<!--startmeta customediturl: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/integrations/amazon_sns.md" meta_yaml: "https://github.com/netdata/netdata/edit/master/integrations/cloud-notifications/metadata.yaml" sidebar_label: "Amazon SNS" learn_status: "Published" learnrelpath: "Alerts & Notifications/Notifications/Centralized Cloud Notifications" message: "DO NOT EDIT THIS FILE DIRECTLY, IT IS GENERATED BY THE NOTIFICATION'S metadata.yaml FILE" endmeta--> <img src="https://netdata.cloud/img/awssns.png" width="150"/> From the Cloud interface, you can manage your space's notification settings and from these you can add a specific configuration to get notifications delivered on AWS SNS. <img src="https://img.shields.io/badge/maintained%20by-Netdata-%2300ab44" /> To add AWS SNS notification you need: A Netdata Cloud account Access to the space as an Admin The Space needs to be on a paid plan Have an AWS account with AWS SNS access, for more details check Click on the Space settings cog (located above your profile icon) Click on the Notification tab Click on the + Add configuration button (near the top-right corner of your screen) On the AwsSns card click on + Add A modal will be presented to you to enter the required details to enable the configuration: Notification settings* are Netdata specific settings Configuration name - you can optionally provide a name for your configuration you can easily refer to it Rooms - by specifying a list of Rooms you are select to which nodes or areas of your infrastructure you want to be notified using this configuration Notification - you specify which notifications you want to be notified using this configuration: All Alerts and unreachable, All Alerts, Critical only Integration configuration* are the specific notification integration required settings, which vary by notification method. For AWS SNS: Topic ARN - topic provided on AWS SNS (with region) for where to publish your notifications. For more details check To enable the webhook integration on AWS SNS you need: Create a topic On AWS SNS management console click on Create topic On the Details section, the standard type and provide the topic name On the Access policy section, change the Publishers option to Only the specified AWS accounts and provide the Netdata AWS account (123269920060) that will be used to publish notifications to the topic being created Finally, click on Create topic on the bottom of the page Now, use the new Topic ARN while adding AWS SNS integration on your space.
Project: Vector (Observability and Analysis / Observability)
File: 2022-07-07-sink-codecs.md

date: "2021-07-07" title: "New `encoding` and `framing` options for sinks" description: "" authors: ["jszwedko"] pr_numbers: [] release: "0.23.0" hideonrelease_notes: false badges: type: "announcement" Sinks that allow codecs have been updated to allow analogous options to those that were . This means you can now, rather than just specifying `encoding.codec`, you can now supply custom `framing` options. Additionally, the supported codecs (`encoding.codec`) for each sink was expanded to be a uniform set of codecs. For example, if you have a `socket` sink that you want to send JSON-encoded, messages, you can now do so with configuration like: ```toml [sinks.socket] type = "socket" address = "92.12.333.224:5000" mode = "tcp" framing.method = "length_delimited" encoding.codec = "json" ``` This will encode messages flowing into this sink as JSON and frame them using framing.
Project: Checkmk (Observability and Analysis / Observability)
File: 15724.md

key | value | date | 2024-02-17T13:24:38+00:00 version | 2.4.0b1 class | fix edition | cre component | rest-api level | 2 compatible | yes The specification of the REST API defines the structure of the API. It is computed automatically from the implementation in Checkmk. Previously the specification was computed during runtime when something requested access to the specification. This could be a user opening ReDoc or the Swagger UI. The specification was then computed ad-hoc and cached in the memory of the apache process. This caused several issues: After spawning a new apache, the specification needed to be recomputed for every process. This caused a delay in the first request hitting an apache process asking for it. It was held in memory by every process consuming a few MB. The invalidation of the cache and computation of new specification could not be triggered manually. With this change the specification is now stored in the site and made available to all apache processes from there. With the dedicated command `cmk-compute-api-spec` the computation can now be triggered in specific situations automatically or manually for debugging. The specification is now updated in these situations: post-create hook: Create the initial spec after a site has been created post rename action: Update the spec after a site has been copied, restored or renamed update-config action: Update the spec after the site has been updated
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: segment.md

title: Segment Integration description: Integrate Flagsmith with Segment sidebar_label: Segment hide_title: true You can integrate Flagsmith with Segment. Send your Identity flag states into segment for further downstream analysis. Get the Segment API key for your Segment project. Add an HTTP API source, and make a note of the `Write Key`. Go to your Flagsmith project, and click Integrations. Add the Segment Integration. Paste the `Write Key` from step 1 into the API Key field in Flagsmith. Select the Flagsmith Environment that you want to send events from. Then hit Save. All API calls generated by the Flagsmith SDK to the `Get Identity Flags` endpoint will send the a full set of flag evaluations for that particular user to the Segment :::tip For flags that contain remote config values, Flagsmith will pass the value of the flag to Segment if the flag is `enabled`. If the flag has no remote config value, Flagsmith will just pass the boolean state for the flag. ::: Identity flag values are passed into Segment. If we make the call to the Flagsmith API to get the flags for an Identity: ```bash curl 'https://edge.api.flagsmith.com/api/v1/identities/?identifier=developmentuser123456' \ -H 'x-environment-key: 8KzETdDeMY7xkqkSkY3Gsg' ``` And then take a look in our Segment dashboard, you can see the user and the flag data that has been sent to the Segment platform. Once the integration has been set up, you can start segmenting your Segment identities based on the flags that they saw. This means you can run AB tests driven by Flagsmith segments, and have the data show up automatically in Segment. You have to identify users on both platforms in the same way. The Flagsmith `Identity ID` must be the same as the Segment `user_id`.
Project: Flagsmith (Observability and Analysis / Feature Flagging)
File: CONTRIBUTING.md

We're always looking to improve this project! Open source contribution is encouraged so long as they adhere to these guidelines. The Flagsmith team will be monitoring for pull requests. When we get one, a member of team will test the work against our internal uses and sign off on the changes. From here, we'll either merge the pull request or provide feedback suggesting the next steps. If you've changed APIs, update the documentation. Keep the code style (indents, wrapping) consistent. If your PR involves a lot of commits, squash them using `git rebase -i` as this makes it easier for us to review. Keep lines under 80 characters. The application uses pre-commit configuration ( `.pre-commit-config.yaml` ) to run `black`, `flake8` and `isort` formatting before commits. To install pre-commit: ```bash make install pre-commit install ``` You can also manually run all the checks across the entire codebase with: ```bash pre-commit run --all-files ``` The application uses pytest for writing (appropriate use of fixtures) and running tests. Before running tests please make sure that `DJANGOSETTINGSMODULE` env var is pointing to the right module, e.g. `app.settings.test`. To run tests: ```bash DJANGOSETTINGSMODULE=app.settings.test pytest ``` We use for dependency management - please follow .
Project: HertzBeat (Observability and Analysis / Observability)
File: memcached.md

id: memcached title: Monitoring Memcached sidebar_label: Memcached Monitor keywords: [ open source monitoring tool, open source Memcached monitoring tool, monitoring memcached metrics ] Collect and monitor the general performance Metrics of Memcached. Protocol UseMemcached ```text The default YML configuration for the memcache version is in compliance with 1.4.15. You need to use the stats command to view the parameters that your memcache can monitor ``` 1Obtain usable parameter indicators through commands such as statsstats settingstats settings. ```shell [root@server ~]# telnet localhost 11211 Trying ::1... Connected to localhost. Escape character is '^]'. stats STAT pid 15168 STAT uptime 11691 STAT time 1702569246 STAT version 1.4.15 ... ``` There is help_doc: https://www.runoob.com/memcached/memcached-stats.html | Parameter name | Parameter help description | ||| | Monitoring Host | Monitored IPV4, IPV6 or domain name. NoteWithout protocol header (eg: https://, http://) | | Monitoring name | Identify the name of this monitoring. The name needs to be unique | | Port | Port provided by Memcached | | Collection interval | Interval time of monitor periodic data collection, unit: second, and the minimum interval that can be set is 30 seconds | | Whether to detect | Whether to detect and check the availability of monitoring before adding monitoring. Adding and modifying operations will continue only after the detection is successful | | Description remarks | For more information about identifying and describing this monitoring, users can note information here | | Metric name | Metric unit | Metric help description | ||-|| | pid | | Memcache server process ID | | uptime | s | The number of seconds the server has been running | | version | | Memcache version | | curr_connections | | Current number of connections | | auth_errors | | Number of authentication failures | | threads | | Current number of threads | | item_size | byte | The size of the item | | item_count | | Number of items | | curr_items | | The total number of data currently stored | | total_items | | The total number of data stored since startup | | bytes | byte | The current number of bytes occupied by storage | | cmd_get | | Get command request count | | cmd_set | | Set command request count | | cmd_flush | | Flush command request count | | get_misses | | Get command misses | | delete_misses | | Delete command misses |
Project: Vector (Observability and Analysis / Observability)
File: 2021-02-16-reduce-transform-remap-support.md

date: "2021-02-16" title: "Remap support for the `reduce` transform (multi-line logs)" short: "Reduce in Remap" description: "Use VRL to specify conditions for reducing multi-log lines into a single log event" authors: ["lucperkins"] pr_numbers: [] release: "0.12.0" hideonrelease_notes: false badges: type: "enhancement" transforms: ["reduce"] The transform for Vector enables you to reduce multiple log events into a single event, which is useful for logs that are split across multiple lines, such as JVM stack traces. With `reduce` you can specify both a merge strategy for the events and a condition for specifying when a group of events either starts or ends (that group is then collapsed, i.e. reduced into a single event). Previously, the `reduce` transform required you to specify conditions using `check_fields`. But now you can use Vector Remap Language expressions in the transform to specify those conditions. This should make using `reduce` more natural and expressive. The example configuration below shows the same `reduce` transform using the old system (`check_fields`) and the new system (`remap`): ```diff [transforms.mergestacktrace] type = "reduce" inputs = ["jvm-logs"] mergestrategies.message = "concatnewline" -startswhen.type = "checkfields" -starts_when.message.regex = "/^\\w.*/" -starts_when.severity.eq = "info" +starts_when.type = "remap" +starts_when.source = 'match(string!(.message), r'^\\w.*') && .severity == "info"' ```
Project: Elastic APM (Observability and Analysis / Observability)
File: rally.md

As we make changes to the way APM Server indexes documents, we may alter the performance of indexing or queries, and we may alter our storage efficiency. We can use for benchmarking these. Rally was designed with a focus on benchmarking Elasticsearch: given a set of documents, what is the performance of indexing? Querying? Deleting? And so on. Typically one will produce a corpus (set of documents), and then run the benchmark with varying versions of Elasticsearch, or on varying hardware profiles. This is almost what we want. Like Elasticsearch, the Elastic APM product evolves over time. In practice, that means: documents produced by APM Server change shape processing moves from APM Server to ingest node (and vice versa) queries made by APM UI change If we were to benchmark with a fixed Elasticsearch document corpus over time, we would not be able to measure the impact of the first two points. Therefore we use Rally in a slightly unconventional way. Instead of storing fixed Elasticsearch document corpora, we instead maintain fixed corpora of APM events. We translate these at benchmark time to the current document structure, using the APM Server binary. This can be achieved with `make rally/corpora`. We install the current APM integration package via Fleet, to ensure the current index templates and ingest pipelines are defined. We then run the corpora through Rally as usual, with `make rally`. Rally benchmarks can also be run on Elastic Cloud with a locally built APM Server and APM integration package. This is achieved by pushing the locally built images to an internal docker registry. Follow for more details. This tells us little about the change in processing performance of APM Server, or the overall ingest performance. For example if we move processing from APM Server to ingest node, we may identify an increase in Elasticsearch processing time, but this may be offset by a decrease in APM Server processing time which we will not observe. We have separate tooling (apmbench) for macrobenchmarking the entire ingest process, from agent to APM Server to Elasticsearch. Our use of Rally is purely focused on analysing Elasticsearch ingest performance, query performance, and storage efficiency.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-dashboard_graph_create.md

category: DashboardGraph apiurl: '/api/v1/dashboard/graph' title: 'Create User' type: 'POST' sample_doc: 'dashboard.html' layout: default Required ``` { "screen_id": 953, "title": "laiwei-test-graph1", "endpoints": ["laiweiofficemac"], "counters": ["value/name=pfc.push.ms","value/name=pfc.push.size"], "timespan": 1800, "graph_type": "h", "method": "AVG", "position": 0 } ``` ```Status: 200``` ```{"message":"ok"}``` For errors responses, see the .
Project: VictoriaMetrics (Observability and Analysis / Observability)
File: Overview.md

sort: 1 weight: 1 title: Overview of Managed VictoriaMetrics menu: docs: parent: "managed" weight: 1 aliases: /managed-victoriametrics/overview.html VictoriaMetrics is a fast and easy-to-use monitoring solution and time series database. It integrates well with existing monitoring systems such as Grafana, Prometheus, Graphite, InfluxDB, OpenTSDB and DataDog - see for details. The most common use cases for VictoriaMetrics are: Long-term remote storage for Prometheus; More efficient drop-in replacement for Prometheus and Graphite Replacement for InfluxDB and OpenTSDB, which uses lower amounts of RAM, CPU and disk; Cost-efficient alternative for DataDog. Managed VictoriaMetrics allows users to run Enterprise version of VictoriaMetrics, hosted on AWS, without the need to perform typical DevOps tasks such as proper configuration, monitoring, logs collection, access protection, software updates, backups, etc. We run Managed VictoriaMetrics instances in our environment on AWS and provide easy-to-use endpoints for data ingestion and querying. The VictoriaMetrics team takes care of optimal configuration and software maintenance. Managed VictoriaMetrics comes with the following features: It can be used as a Managed Prometheus - just configure Prometheus or vmagent to write data to Managed VictoriaMetrics and then use the provided endpoint as a Prometheus datasource in Grafana; Every Managed VictoriaMetrics instance runs in an isolated environment, so instances cannot interfere with each other; Managed VictoriaMetrics instance can be scaled up or scaled down in a few clicks; Automated backups; Pay only for the actually used resources - compute, storage, traffic.
Project: SkyWalking (Observability and Analysis / Observability)
File: mq.md

Message Queue server plays an essential role in today's distributed system to reduce the length and latency of blocking RPC and eventually improve user experience. But in this async way, the measure for queue consuming traffic and latency becomes significant. Since 8.9.0, SkyWalking leverages native tracing agent and [Extension Header Item of SkyWalking Cross Process Propagation Headers Protocol v3](../../api/x-process-propagation-headers-v3.md#extension-header-item) To provide performance monitoring for the Message Queue systems. In default, we provide `Message Queue Consuming Count` and `Message Queue Avg Consuming Latency` metrics for service and endpoint levels. More metrics could be added through `core.oal`.
Project: Loggie (Observability and Analysis / Observability)
File: bug.md

name: Bug report about: Report a bug in Loggie title: '' labels: bug assignees: '' <!-- Remove the '> ' to select /area core /area discovery /area interceptor /area monitoring /area sink /area source --> <!-- Briefly describe what you expect to happen --> <!-- Briefly describe what is actually happening --> <!-- How can a maintainer reproduce this issue (be detailed) -->
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-7-5-3.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 7.5.3 <!-- Auto generated by update changelog github action --> Dashboard: Do not include default data source when externally exporting dashboard with row. , Loki: Remove empty annotations tags. , AdHocVariable: Add default data source to picker. , Configuration: Prevent browser hanging / crashing with large number of org users. , Elasticsearch: Fix bucket script variable duplication in UI. , Explore: Fix bug where navigating to explore would result in wrong query and data source to be shown. , FolderPicker: Prevent drop-down menu from disappearing off screen. , Stat: Fix issue with panel links. , Variables: Confirm selection before opening new picker. , Variables: Confirm selection before opening new picker. , Variables: Fix unsupported data format error for null values. ,
Project: Netdata (Observability and Analysis / Observability)
File: mysql_galera_cluster_state_warn.md

This alert checks the state of a Galera node in a MySQL Galera cluster. If you receive this alert, it means that the node is either in the Donor/Desynced state or the Joined state, which can indicate potential issues within the cluster. Donor/Desynced: When a node is in the Donor/Desynced state, it is providing a State Snapshot Transfer (SST) to another node in the cluster. During this time, the node is not synchronized with the rest of the cluster and cannot process any write or commit requests. Joined: In the Joined state, a node has completed the initial SST and is now catching up with any missing transactions through an Incremental State Transfer (IST). Check the Galera cluster status with the following command: ``` SHOW STATUS LIKE 'wsrep_%'; ``` Verify if any node is in the Donor/Desynced or Joined state: ``` SELECT VARIABLENAME, VARIABLEVALUE FROM informationschema.GLOBALSTATUS WHERE VARIABLENAME IN ('wsreplocalstatecomment', 'wsrepclusterstatus', 'wsrep_ready'); ``` Identify the cause of the node state change. Some possible reasons are: A new node has joined the cluster and requires an SST. A node has been restarted, and it is rejoining the cluster. A node experienced a temporary network issue and is now resynchronizing with the cluster. Monitor the progress of the resynchronization process using the `SHOW STATUS` command, as provided above, and wait for the node to reach the Synced state. If the node remains in the Donor/Desynced or Joined state for an extended period, investigate further to determine the cause of the issue: Inspect the MySQL error log for any relevant messages. Check for network issues or connectivity problems between the nodes. Verify the cluster configuration and ensure all nodes have a consistent configuration. Contact your DBA for assistance if the issue persists, as they may need to perform additional investigation and troubleshooting.
Project: Graylog (Observability and Analysis / Observability)
File: PULL_REQUEST_TEMPLATE.md

<! Provide a general summary of your changes in the Title above --> <! Describe your changes in detail --> <! Why is this change required? What problem does it solve? --> <! If it fixes an open issue, please link to the issue here. --> <! Please describe in detail how you tested your changes. --> <! Include details of your testing environment, and the tests you ran to --> <! see how your change affects other areas of the code, etc. --> <! What types of changes does your code introduce? Put an `x` in all the boxes that apply: --> [ ] Bug fix (non-breaking change which fixes an issue) [ ] New feature (non-breaking change which adds functionality) [ ] Refactoring (non-breaking change) [ ] Breaking change (fix or feature that would cause existing functionality to change) <! Go over all the following points, and put an `x` in all the boxes that apply. --> <! If you're unsure about any of these, don't hesitate to ask. We're here to help! --> [ ] My code follows the code style of this project. [ ] My change requires a change to the documentation. [ ] I have updated the documentation accordingly. [ ] I have read the CONTRIBUTING document. [ ] I have added tests to cover my changes.