log_processing_rules:
- type: exclude_at_match
name: exclude_sensitive_info
pattern: (?:sensitive\-info)
#!/bin/bash | |
# | |
# By Zibri (2019) | |
# Modified by @rokibhasansagar | |
# | |
# Usage: gitclean git-repo-url | |
# | |
gitclean () | |
{ | |
git clone "$1" workDir && { |
import datetime | |
import time | |
import requests | |
import simplejson | |
from datadog import initialize, api | |
""" | |
This script gives a real time report on ec2 and Datadog agent host usage | |
from multiple organizations and reports them up to the 'main' parent account. |
kubectl get pods --all-namespaces | grep Evicted | awk '{print $2 " --namespace=" $1}' | xargs kubectl delete pod |
This document provides a rapid-fire overview of Kubernetes concepts, vocabulary, and operations. The target audience is anyone who runs applications in a cloud environment today, and who wants to understand the basic mechanics of a Kubernetes cluster. The goal is that within 10 minutes, managers who read this should be able to listen in on a Kubernetes conversation and follow along at a high level, and engineers should be ready to deploy a sample app to a toy cluster of their own.
This orientation doc was written because the official Kubernetes docs are a great reference, but they present a small cliff to climb for newcomers.
If you want to understand why you should consider running Kubernetes, see the official Kubernetes conceptual overview document. This document is intended to complement that one, but one layer deeper.
For a deep dive, see [Kubernetes concepts](https://kubernetes.io/docs/co
class ApplicationController < ActionController::Base | |
protect_from_forgery with: :exception | |
around_action :global_request_logging | |
def global_request_logging | |
http_request_header_keys = request.headers.env.keys.select{|header_name| header_name.match("^HTTP.*|^X-User.*")} | |
http_request_headers = request.headers.env.select{|header_name, header_value| http_request_header_keys.index(header_name)} | |
puts '*' * 40 | |
pp request.method |
javascript: | |
document.querySelectorAll('.load-diff-button').forEach(node => node.click()) |
These instructions are known to work with version 5.10.1 of the packaged linux Datadog Agent
Using the AttachAPI can require running JMXFetch as the same user as the JVM you want to monitor.
To run JMXFetch as the jmv_user
user (once you've identified which user your JVM is running as), please follow these steps:
/etc/dd-agent/supervisor.conf
file: supervisord
should be configured to run with user=root
and jmxfetch
with user=jvm_user
. See lines 20 and 58 of the attached file below.jvm_user
to the dd-agent
group (on Debian distros: sudo usermod -G dd-agent jvm_user
, on RHEL: sudo gpasswd -a jvm_user dd-agent
)dd-agent
group write access to the JMXFetch log file and the agent's run
directory (/opt/datadog-agent/run/
):
sudo chmod -R g+w /var/log/datadog/jmxfetch.log /opt/datadog-agent/run/
^3[47][0-9]{13}$
^(6541|6556)[0-9]{12}$
^389[0-9]{11}$
^3(?:0[0-5]|[68][0-9])[0-9]{11}$
^65[4-9][0-9]{13}|64[4-9][0-9]{13}|6011[0-9]{12}|(622(?:12[6-9]|1[3-9][0-9]|[2-8][0-9][0-9]|9[01][0-9]|92[0-5])[0-9]{10})$
^63[7-9][0-9]{13}$
^(?:2131|1800|35\d{3})\d{11}$
^9[0-9]{15}$
garmstrong-ml:config-qa-aws-us-east-1 gary.armstrong$ grep aws_instance terraform.tfstate | |
"aws_instance.bastion": { | |
"type": "aws_instance", | |
garmstrong-ml:config-qa-aws-us-east-1 gary.armstrong$ terraform destroy -target=aws_instance.bastion | |
Do you really want to destroy? | |
Terraform will delete all your managed infrastructure. | |
There is no undo. Only 'yes' will be accepted to confirm. | |
Enter a value: yes |