cwielenb/CNCF-Dataset huggingface dataset:
Project: Grafana (Observability and Analysis / Observability)
File: release-notes-7-3-10.md

_build: list: false labels: products: cloud enterprise oss title: Release notes for Grafana 7.3.10 <!-- Auto generated by update changelog github action --> Security: Fix API permissions issues related to team-sync CVE-2021-28146, CVE-2021-28147. (Enterprise) Security: Usage insights requires signed in users CVE-2021-28148. (Enterprise)
Project: Opstrace (Observability and Analysis / Observability)
File: aws.md

Generally speaking, we subscribe to the . However, since it is common for many developers to have the `AdministratorAccess`, we recommend this as the easiest way to get started on AWS. If you can't get this access or do not want to use it, you will need to build a and . These are the required permissions for the policy: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "autoscaling:CreateAutoScalingGroup", "autoscaling:DeleteAutoScalingGroup", "autoscaling:CreateLaunchConfiguration", "autoscaling:DeleteLaunchConfiguration", "autoscaling:DescribeLaunchConfigurations", "autoscaling:DescribeAutoScalingGroups", "autoscaling:DescribeScalingActivities", "ec2:AllocateAddress", "ec2:AssociateRouteTable", "ec2:AttachInternetGateway", "ec2:AuthorizeSecurityGroupEgress", "ec2:AuthorizeSecurityGroupIngress", "ec2:CreateInternetGateway", "ec2:CreateNatGateway", "ec2:CreateRoute", "ec2:CreateRouteTable", "ec2:CreateSecurityGroup", "ec2:CreateSubnet", "ec2:CreateTags", "ec2:CreateVpc", "ec2:CreateVpcEndpoint", "ec2:DescribeVpcs", "ec2:DescribeVpcAttribute", "ec2:DescribeVpcEndpoints", "ec2:DeleteInternetGateway", "ec2:DeleteNatGateway", "ec2:DeleteRouteTable", "ec2:DeleteSecurityGroup", "ec2:DeleteSubnet", "ec2:DeleteVpc", "ec2:DeleteVpcEndpoints", "ec2:DescribeSubnets", "ec2:DescribeInternetGateways", "ec2:DescribeAddresses", "ec2:DescribeNatGateways", "ec2:DetachInternetGateway", "ec2:DescribeRouteTables", "ec2:DisassociateRouteTable", "ec2:ModifyVpcAttribute", "ec2:ReleaseAddress", "ec2:RevokeSecurityGroupEgress", "ec2:RevokeSecurityGroupIngress", "ec2:DescribeSecurityGroups", "eks:CreateCluster", "eks:DeleteCluster", "eks:DescribeCluster", "eks:TagResource", "eks:ListClusters", "iam:AddRoleToInstanceProfile", "iam:AttachRolePolicy", "iam:CreateInstanceProfile", "iam:CreatePolicy", "iam:CreateRole", "iam:DeleteInstanceProfile", "iam:DeletePolicy", "iam:DeleteRole", "iam:DetachRolePolicy", "iam:RemoveRoleFromInstanceProfile", "iam:ListPolicies", "iam:ListRoles", "iam:PassRole", "iam:GetInstanceProfile", "rds:CreateDBCluster", "rds:CreateDBInstance", "rds:CreateDBSubnetGroup", "rds:DeleteDBCluster", "rds:DeleteDBInstance", "rds:DeleteDBSubnetGroup", "rds:AddTagsToResource", "rds:DescribeDBSubnetGroups", "rds:DescribeDBClusters", "rds:DescribeDBInstances", "route53:CreateHostedZone", "route53:ChangeResourceRecordSets", "route53:ListResourceRecordSets", "route53:DeleteHostedZone", "route53:GetChange", "route53:ListHostedZones", "route53:ListHostedZonesByName", "s3:CreateBucket", "s3:GetLifecycleConfiguration", "s3:PutLifecycleConfiguration", "s3:ListBucket", "sts:GetCallerIdentity", "sts:GetSessionToken", "elasticloadbalancing:DescribeLoadBalancers", "elasticloadbalancing:DeleteLoadBalancer" ], "Resource": "*" }, { "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "*", "Condition": { "StringEquals": { "iam:AWSServiceName": [ "autoscaling.amazonaws.com", "eks.amazonaws.com", "elasticloadbalancing.amazonaws.com" ] } } } ] } ```
Project: Netdata (Observability and Analysis / Observability)
File: gcp.md

<!-- title: "Install Netdata on GCP" description: "The Netdata Agent runs on all popular cloud providers, but often requires additional steps and configuration for full functionality." customediturl: https://github.com/netdata/netdata/edit/master/packaging/installer/methods/gcp.md sidebar_label: "GCP" learn_status: "Published" learntopictype: "Tasks" learnrelpath: "Installation/Install on specific environments" --> Netdata is fully compatible with the Google Cloud Platform (GCP). You can install Netdata on cloud instances to monitor the apps/services running there, or use multiple instances in a configuration. The best installation method depends on the instance's operating system, distribution, and version. For Linux instances, we recommend the . If you have issues with Netdata after installation, look to the sections below to find the issue you're experiencing, followed by the solution for your provider. If you cannot access Netdata's dashboard on your cloud instance via `http://HOST:19999`, and instead get an error page from your browser that says, "This site can't be reached" (Chrome) or "Unable to connect" (Firefox), you may need to configure your cloud provider's firewall. Cloud providers often create network-level firewalls that run separately from the instance itself. Both AWS and Google Cloud Platform calls them Virtual Private Cloud (VPC) networks. These firewalls can apply even if you've disabled firewalls on the instance itself. Because you can modify these firewalls only via the cloud provider's web interface, it's easy to overlook them when trying to configure and access Netdata's dashboard. You can often confirm a firewall issue by querying the dashboard while connected to the instance via SSH: `curl http://localhost:19999/api/v1/info`. If you see JSON output, Netdata is running properly. If you try the same `curl` command from a remote system, and it fails, it's likely that a firewall is blocking your requests. Another option is to put Netdata behind web server, which will proxy requests through standard HTTP/HTTPS ports (80/443), which are likely already open on your instance. We have a number of guides available: To add a firewall rule, go to the and click Create firewall rule. The following configuration has previously worked for Netdata running on GCP instances (): ```conf Name: <name> Type: Ingress Targets: <name-tag> Filters: 0.0.0.0/0 Protocols/ports: 19999 Action: allow Priority: 1000 ``` Read GCP's for specific instructions on how to create a new firewall rule.
Project: Netdata (Observability and Analysis / Observability)
File: web_log_web_slow.md

The `weblogweb_slow` alert is triggered when the average HTTP response time of your web server (NGINX, Apache) has increased over the last minute. It indicates that your web server's performance might be affected, resulting in slow response times for client requests. There are several factors that can cause slow web server performance. To troubleshoot the `weblogweb_slow` alert, examine the following areas: Monitor web server utilization: Use monitoring tools like `top`, `htop`, or `glances` to check the CPU, memory, and traffic utilization of your web server. If you find high resource usage, consider taking action to address the issue: Increase your server's resources (CPU, memory) or move to a more powerful machine. Adjust the web server configuration to use more worker processes or threads. Implement load balancing across multiple web servers to distribute the traffic load. Optimize databases: Slow database performance can directly impact web server response times. Monitor and optimize your database to improve response speeds: Check for slow or inefficient queries and optimize them. Regularly clean and optimize your database by removing outdated or unnecessary data, and by using tools like `mysqlcheck` or `pg_dump`. Enable database caching for faster results on recurring queries. Configure caching: Implement browser or server-side caching to reduce the load on your web server and speed up content delivery: Enable browser caching using proper cache-control headers in your server configuration. Implement server-side caching with tools like Varnish or use full-page caching in your web server (NGINX FastCGI cache, Apache mod_cache). Examine web server logs: Analyze your web server logs to identify specific requests or resources that may be causing slow responses. Tools like `goaccess` or `awstats` can help you analyze web server logs and identify issues: Check for slow request URIs or resources and optimize them. Identify slow third-party services, such as CDNs, external APIs, or database connections, and troubleshoot these connections as needed. Optimize web server configuration: Review your web server's configuration settings to ensure optimal performance: Ensure that your web server is using the latest stable version for performance improvements and security updates. Disable unnecessary modules or features to reduce resource usage. Review and optimize settings related to timeouts, buffer sizes, and compression for better performance.
Project: Grafana Tempo (Observability and Analysis / Observability)
File: traceql-editor.md

description: Learn how to create TraceQL queries in Grafana using the query editor. keywords: grafana tempo traces queries menuTitle: Write TraceQL queries title: Write TraceQL queries with the editor {{< docs/shared source="grafana" lookup="datasources/tempo-editor-traceql.md" version="<GRAFANA_VERSION>" >}}
Project: GO Feature Flag (Observability and Analysis / Feature Flagging)
File: index.md

title: Home description: go-feature-flag is a simple and complete feature flag solution, without any complex backend system to install. You need only a file as your backend. sidebar_position: 1 <p align="center"> <img width="250" height="238" src="/img/logo/logo.png" alt="go-feature-flag logo" /> </p> GO Feature Flag is a simple, complete and lightweight feature flag solution 100% opensource. The solution has been built to start experiencing the usage of feature flags in your code without having to contract with any vendor. GO Feature Flag has started to be a solution only for the GO language, but with the new standardisation of feature flags by project, now the solution is available for multiple languages (`JAVA`, `typescript`, `javascript`, ...) with a simple server to host. :::info If you are not familiar with feature flags, also called feature toggles, you can read this where he explains why this is a great pattern. I've also written an which explains why feature flags can fasten your iteration cycle. ::: Storing your configuration flags file on various locations (`HTTP`, `S3`, `Kubernetes`, ). Configuring your flags in various (`JSON`, `TOML` and `YAML`). Adding complex to target your users. Use complex rollout strategy for your flags : . . . Exporting your flags usage data (, , , ). Getting notified when a flag has been changed ( and ). Use GO Feature Flag in several languages.
Project: SkyWalking (Observability and Analysis / Observability)
File: mysql.md

Activate MySQL as storage, and set storage provider to mysql. NOTE: MySQL driver is NOT allowed in Apache official distribution and source codes. Please download the MySQL driver on your own. Copy the connection driver jar to `oap-libs`. ```yaml storage: selector: ${SW_STORAGE:mysql} mysql: properties: jdbcUrl: ${SWJDBCURL:"jdbc:mysql://localhost:3306/swtest?rewriteBatchedStatements=true&allowMultiQueries=true"} dataSource.user: ${SWDATASOURCE_USER:root} dataSource.password: ${SWDATASOURCE_PASSWORD:root@1234} dataSource.cachePrepStmts: ${SWDATASOURCECACHEPREP_STMTS:true} dataSource.prepStmtCacheSize: ${SWDATASOURCEPREPSTMTCACHESQL_SIZE:250} dataSource.prepStmtCacheSqlLimit: ${SWDATASOURCEPREPSTMTCACHESQL_LIMIT:2048} dataSource.useServerPrepStmts: ${SWDATASOURCEUSESERVERPREPSTMTS:true} metadataQueryMaxSize: ${SWSTORAGEMYSQLQUERYMAX_SIZE:5000} maxSizeOfBatchSql: ${SWSTORAGEMAXSIZEOFBATCHSQL:2000} asyncBatchPersistentPoolSize: ${SWSTORAGEASYNCBATCHPERSISTENTPOOLSIZE:4} ``` All connection-related settings, including URL link, username, and password, are found in `application.yml`. Only part of the settings is listed here. See the connection pool document for full settings. To understand the function of the parameter `rewriteBatchedStatements=true` in MySQL, see the MySQL official document for more details. In theory, all other databases that are compatible with MySQL protocol should be able to use this storage plugin, such as TiDB. Please compose the JDBC URL according to the database's documentation.
Project: Falcon (Observability and Analysis / Observability)
File: 2017-01-01-strategy_delete.md

category: Strategy apiurl: '/api/v1/strategy/#{strategy_id}' title: "Delete Strategy" type: 'DELETE' sample_doc: 'template.html' layout: default Required ex. /api/v1/strategy/904 ```Status: 200``` ```{"message":"strategy:904 has been deleted"}```
Project: HertzBeat (Observability and Analysis / Observability)
File: alert_smn.md

id: alert_smn title: Alert Huawei Cloud SMN Notifications sidebar_label: Alert Huawei Cloud SMN Notifications keywords: [ open source monitoring tool, open source alerter, open source Huawei Cloud SMN notification ] Send an alarm message after the threshold is triggered, and notify the recipient through the Huawei Cloud SMN. According to activate the SMN service and configure SMN Save topic URN for SMN According to obtain AK, SK, and project ID Alarm Notification->Add Recipient->Select Slack Webhook Notification Method->Set Huawei Cloud SMN AK, SK and other configurations-> OK Configure the associated alarm notification strategy [Add notification strategy] -> [Associate the recipient just set] -> [OK] Note Adding a new recipient does not mean that it has taken effect and can receive alarm information. It is also necessary to configure the associated alarm notification strategy, that is, specify which messages are sent to which recipients. Huawei Cloud SMN did not receive the robot warning notification Please check whether the alarm information has been triggered in the alarm center Please check whether the Huawei Cloud SMN AK, SK and other configurations are configured correctly, and whether the alarm policy association has been configured Other questions can be fed back through the communication group ISSUE!
Project: Inspektor Gadget (Observability and Analysis / Observability)
File: ebpftop.md

title: Gadget ebpftop ebpftop shows cpu time used by ebpf programs. The following parameters are supported: interval: Output interval, in seconds. (default 1) max_rows: Maximum rows to print. (default 20) sort_by: The field to sort the results by (runtime.runtimeName,runtime.containerId,runtime.containerName,runtime.containerImageName,runtime.containerImageDigest,k8s.node,k8s.namespace,k8s.pod,k8s.labels,k8s.container,k8s.hostnetwork,progid,type,name,runtime,runcount,cumulruntime,cumulruncount,totalruntime,totalRunCount,mapmemory,mapcount,totalcpu,percpu). (default -runtime,-runcount) ```yaml apiVersion: gadget.kinvolk.io/v1alpha1 kind: Trace metadata: name: ebpftop namespace: gadget spec: node: ubuntu-hirsute gadget: ebpftop runMode: Manual outputMode: Stream parameters: interval: "1" max_rows: "50" sort_by: all # all, runtime, runcount, progid, totalruntime, totalruncount, cumulruntime, cumulrouncount, mapmemory and mapcount are allowed ``` Start ebpftop gadget ```bash $ kubectl annotate -n gadget trace/ebpftop \ gadget.kinvolk.io/operation=start ``` Stop ebpftop gadget ```bash $ kubectl annotate -n gadget trace/ebpftop \ gadget.kinvolk.io/operation=stop ``` Stream
Project: Pinpoint (Observability and Analysis / Observability)
File: feature_request.md

name: Feature request about: Suggest an idea for this project Which module is your feature request related to? Plugin/UI etc Is your feature request related to a problem? A clear and concise description of what the problem is. Describe the solution you'd like A clear and concise description of what you want to happen. Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered. Additional context Add any other context or screenshots about the feature request here.
Project: Checkmk (Observability and Analysis / Observability)
File: 16639.md

key | value | date | 2024-03-13T09:20:05+00:00 version | 2.4.0b1 class | fix edition | cre component | checks level | 1 compatible | yes Previously the help text configured for SimpleLevels and Levels was not shown in the UI, this is now fixed.
Project: Elastic (Observability and Analysis / Observability)
File: signum.md

<!-- This is generated by ESQL's AbstractFunctionTestCase. Do no edit it. See ../README.md for how to regenerate it. --> Returns the sign of the given number. It returns `-1` for negative numbers, `0` for `0` and `1` for positive numbers. ``` ROW d = 100.0 | EVAL s = SIGNUM(d) ```
Project: Checkmk (Observability and Analysis / Observability)
File: 16779.md

key | value | date | 2024-04-18T14:03:11+00:00 version | 2.4.0b1 class | fix edition | cme component | wato level | 1 compatible | yes When an ldap connection is configured for a specific customer, this wasn't reflected in the users for that ldap connection. This werk addresses this issue by now showing the correct customer.
Project: Vector (Observability and Analysis / Observability)
File: 2021-11-18-0-18-0-upgrade-guide.md

date: "2021-11-18" title: "0.18 Upgrade Guide" description: "An upgrade guide that addresses breaking changes in 0.18.0" authors: ["tobz"] pr_numbers: [] release: "0.18.0" hideonrelease_notes: false badges: type: breaking change Vector's 0.18.0 release includes breaking changes: We cover them below to help you upgrade quickly: We've finally removed the `batch.max_size` parameter from sinks that support batching. In the past, this field allowed settings the maximum batch size in a general way, being interpreted by the sink to mean either bytes or events. As we add more and more sinks, some which support the notion of batches being limited by both bytes and events, we've removed `max_size` as a way to ensure every configuration is clear as to what is being limited rather than forcing users to dig into the documentation to understand how the sink will interpret `max_size`. If you're currently setting this, you will need to switch to either `batch.max_bytes` or `batch.max_events`. If you're trying to limit the size of the batch, in terms of bytes, you should use `batch.max_bytes`. Otherwise, if you're trying to limit the size of the batch in terms of events, you should use `batch.max_events`. Similarly to `batch.max_size`, we've had support for adjusting the concurrency of sources and sinks via `request.concurrency` for some time now. This is the preferred field to set, and is referenced in all of our documentation. `request.concurrency` and `request.inflightlimit` were both treated the same internally, so simply renaming any instances of `request.inflightlimit` in your configurations to `request.concurrency` is enough to address this change. The `httpclientresponses_total` internal metric has a `status` label indicating the HTTP status code of the response. Previously, this label included the canonical reason, for example the `OK` in `200 OK`; however, this was an oversight. It was meant to only include the numeric value, `200`. With this release, the `status` label for this metric only includes the code and not the canonical reason. Having only the numeric value makes it easier to group status codes (for example all `2xx` level status codes) in downstream metrics systems. We've updated the rendered fields for "aggregated summaries" when emitted by the `metrictolog` transform to better align with the actual data itself. Instead of `upper_limit`, the field which holds the quantile is now called `q`, which is a common shorthand for "quantile". `upper_limit` is a holdover from the initial implementation of metrics support in Vector and applies to aggregated histograms, but not to aggregated summaries. As part of our continued efforts to keep the configuration and documentation for Vector as clean as possible, we're removing two deprecated configuration fields from the Datadog Metrics sink: `host` and `namespace`. It's finally time to remove the cruft! You can migrate your configuration simply by switching to `endpoint` and `default_namespace` instead.
Project: Tracetest (Observability and Analysis / Observability)
File: TESTING.md

On Tracetest, we work in two ways to test the entire system and guarantee that everything is working fine. One is through automatic tests, where we run unit, integration and end-to-end tests on Tracetest CLI, Web UI and Server. Another source of tests is the manual tests that we execute on each release, simulating users, and checking if everything is ok on these tests. On our manual tests, we aim to do some to see if the main features are working as expected. Usually, we run it on each Tracetest release. This is a simple test to check if Tracetest is working correctly given it was provisioned with one Tracing Data Store. The steps that we should follow are: [ ] Open WebUI and go to `/settings` page. The provisioned Data Store should be selected. [ ] Run `tracetest export datastore --id current` and check if the data was exported correctly. or ). This test should fetch traces correctly and run without errors. This is the entire checklist on what we should do to assert that Tracetest is working fine on each version release. On each version release, we can copy the contents of this checklist and open a Github Discussion to start each test. workflow on Github Actions worked correctly. doc and see if everything is documented correctly Test server installation via CLI [ ] Docker Compose and no demo API [ ] Docker Compose and demo API [ ] Kubernetes and no demo API [ ] Kubernetes and demo API Test Tracetest examples - - - - Test specific features added/changed on this release: [ ] Add features here Test CLI updates [ ] MacOS via homebrew [ ] MacOS via curl script [ ] Windows via chocolatey [ ] Windows via manual download Test specific features added/changed on this release: [ ] Add features here Today Tracetest has 3 main components: a WebUI, a CLI and a Server. Unit tests: Run by executing `npm test` on `./web` folder End-to-end tests: Run using against a temporary Tracetest created on Kubernetes. Unit tests: Run by executing `make test` on `./cli` folder Unit tests: Run by executing `make test` on `./server` folder Integration tests: Run along with some unit tests running `make test` on `./server` folder, but also done in a matrix test on Github actions, by executing the `test-examples` action. End-to-end tests: Run using Tracetest to test itself. We deploy two instances of Tracetest and use one to test API calls to another on Github actions, by executing the `trace-testing` action.
Project: Vector (Observability and Analysis / Observability)
File: 2021-12-14-improved-concurrency-model.md

date: "2021-12-14" title: "Improved concurrency model" description: "New parallel processing with improved performance" authors: ["barieom"] pr_numbers: [10265] release: "0.19.0" hideonrelease_notes: false badges: type: announcement We've released an improved concurrency model that provides measurable performance improvements and enables more efficient vertical scaling. Previously, Vector was limited to executing transforms on a single thread per transform, which led to them often being the bottleneck in Vector pipelines. With this new release, Vector will perform faster when a transform is a bottleneck, assuming that more CPUs are available to share their work. This works by Vector determining whether an individual transform will be processed in parallel when there is a sufficient load to the environment. This improvement works by spinning up multiple short-lived tasks that concurrently run the same transform logic on separate batches of events. No configuration changes are necessary to start taking advantage of this feature. The current list of transforms that support parallelization are: `metrictolog` `filter` `logtometric` `remap` But we will be rolling this out this support to more transforms soon. If you any feedback for us, let us know on our [Discord chat] or on [Twitter].