Another major use of variables is running a command and using the result of that command to save the result into a variable

- hosts: all
  tasks:
  - name: Ansible register variable basic example
    shell: "find *.txt"
    args:
      chdir: "/Users/mdtutorials2/Documents/Ansible"
    register: find_output

  - debug:
      var: find_output

#
- hosts: all
  tasks:
  - name: Ansible register with_items example
    shell: "find *.txt"
    args:
      chdir: "/Users/mdtutorials2/Documents/Ansible"
    register: with_output

  - shell: "cp {{ item }} {{item}}_bkp"
    with_items:
      - "{{ with_output.stdout_lines }}"

The post Use of runtime variables to save into another variable using register in Ansible appeared first on scmGalaxy.

The post Ansible & Ansible Tower Variable Precedence Hierarchy appeared first on scmGalaxy.

##### Step 1 – Create your inventory file with #####

$ vi inventory
35.154.85.120 ansible_user=root ansible_ssh_private_key_file=remote.pem
35.154.85.120 ansible_user=root ansible_ssh_private_key_file=remote.pem

##### Step 2 – Create templates directory #####

$ mkdir templates
$ vi templates/index.j2

<!DOCTYPE html>
<html>
<body>
<h1> Welcome to DevOpsSchool.com Ansible Training</h1>
<h3> This is Deployed in OS Family - {{ ansible_os_family }} </h3>
<h3> This is Deployed in OS Family - {{ ansible_hostname }} </h3>
<h3> Company Name - {{ companyname }} </h3>
companyname

</body>
</html>

<strong>##### Step 3 – Create a playbook.yaml#####</strong>

---
- name: This sets up an httpd webserver
hosts: all
remote_user: ec2-user
become: yes
vars:
ansible_ssh_private_key_file: remote.pem
companyname: DevOpsSchool.com
pack: httpd
tasks:
- name: Install the httpd apps
yum: name={{ pack }}
- name: Deploy configuration File
template: src=templates/index.j2 dest=/var/www/html/index.html
- name: start the httpd service
service: name={{ pack }} state=started

##### Step 4 – Last comamds to execute #####

$ ansible-playbook -i inventory httpd.yaml

The post How to use template in Ansible? appeared first on scmGalaxy.

Ansible can’t run playbooks locally without ssh if ansible_connection=local is defined in the hosts file, although it can run playbooks locally without ssh with connection: local in the playbook or with flag –connection=local.

# # # # # # # # # # # # Method 1 # # # # # # # # # # # # # # # # # #

ansible 127.0.0.1 -m file -a "dest=/opt/a.txt mode=600 state=touch"
ansible 127.0.0.1 -m file -a "dest=/opt/a.txt mode=600 state=file"

# # # # # # # # # # # # Method 2 # # # # # # # # # # # # # # # # # #

Inventory file
127.0.0.1 ansible_connection=local
localhost ansible_connection=local

# # # # # # # # # # # # Method 3 # # # # # # # # # # # # # # # # # #

---

- name: run the playbook tasks on the localhost
hosts: 127.0.0.1
connection: local
become: yes
tasks:

- name: print out the hostname of target
command: hostname

- name: ensure aptitude is installed
command: apt-get -y install aptitude

- name: update the apt package index i.e. apt-get update
apt: update_cache=yes

- name: upgrade system packages i.e. apt-get upgrade
apt: upgrade=yes

The post Run Ansible Adhoc commands or playbook in Local mode appeared first on scmGalaxy.

1. Write a Ansible Playbook to create a group called “deploy”

2. Write a Ansible Playbook to create a user called “deploy-user” which is part of group called “group” and with /bin/bash shell.

3. Write a Ansible Playbook to install package named “httpd” in RHEL/centos.

4. Write a Ansible Playbook to start and enable the service named “httpd”

5. Write a Ansible Playbook to create a file called “index.html” in /var/www/html with some dummy html contents.

6. Write a Ansible Playbook to reboot a self machine.

7. Write a Ansible Playbook to install a package called “git”, “wget”.

8. Write a Ansible Playbook to clone git repo. thttps://github.com/scmgalaxy/ansible-role-template

9. Now Merge all Top Playbook into one and run and verify

The post Ansible Playbook Lab & Excercise – Part 2 appeared first on scmGalaxy.

1. Write a Ansible Adhoc Commands to create a group called “deploy”

2. Write a Ansible Adhoc Commands to create a user called “deploy-user” which is part of group called “group” and with /bin/bash shell.

3. Write a Ansble Adhoc commands install package named “httpd” in RHEL/centos.

4. Write a Ansible Adhoc commands to start and enable the service named “httpd”

5. Write a Ansible commands to create a file called “index.html” in /var/www/html with some dummy html contents.

6. Write a Ansible commands to reboot a self machine.

7. Write a Ansible commands to install a package called “git”, “wget”.

8. Write a Ansible Adhoc commands to clone git repo. thttps://github.com/scmgalaxy/ansible-role-template

The post Ansible Adhoc Commands Lab & Excercise – Part 1 appeared first on scmGalaxy.

1. Write a puppet module to setup a webserver(httpd) only in RHEL and use the HEREDOC to craete a html code of index.html inside a directory called “/var/www/html/index.html”

2. Write a puppet module to setup a webserver(httpd) only in RHEL and use the puppet template to create a html code of index.html inside a directory called “/var/www/html/index.html”

3. Write a puppet module to install git, ntp and wget tools.

4. Write a puppet module which has file named with deploy.sh under module’s files directory. the file should be copied to /opt

The post Puppet Module Lab & Excercise – Part 1 appeared first on scmGalaxy.

1. Write a puppet Program to install package “git”, “ntp” and wget in RHEL.

2. Which resource declaration can help us to deploy the “~/.ssh/authorized_keys” in 1000s of servers?

3. Write a puppet Program to extract a tar ball in /opt

4. Write a puppet Program to zip a directory which has multiple files.

5. Write a puppet Program to reboot the machine?

6. Write a puppet program to execute a shell command/script using puppet.

The post Puppet Program Lab & Excercise – Part 2 appeared first on scmGalaxy.

1. Write a Puppet Program to create a file named with “file.txt” in /opt/ owner by ec2-user and execute permission?
2. Write a Puppet Program to create a group called “scmgalaxy-admins”
3. Write a Puppet Program to create a usser called “deploy” which should be a part of “scmgalaxy-admins” group.
4. Wrire a Puppet Program and insert following in /etc/hosts
   10.4.5.5 test.scmgalaxy.com
5. Write a puppet program to display following lines when Sends an arbitrary message to the agent run-time log.
   Welcome to scmGalaxy Puppet program

The post Puppet Program Lab & Excercise – Part 1 appeared first on scmGalaxy.

Enforce the JIRA issue id in a GIT commit message

This can be done by using git hooks file location at .git/hooks/commit-msg. Following are the 2 way in whcih each Developers can set the Hooks in their developement envioronment.

Method – 1

# commit-msg.sh
#!/bin/sh
# This hook will make sure that the commit message contains a JIRA issue.
#
# To enable this hook, rename this file to ".git/hooks/commit-msg".
# Make sure to add execution permissions to the file.

export MESSAGE=$(<$1)
export JIRA_ISSUE_TAG='ISSUETAG-([0-9]*)'

if [[ $MESSAGE =~ $JIRA_ISSUE_TAG ]]; then
echo -e "\e[32mGreat, your commit message contains a JIRA issue!\e[0m"
exit 0;
fi

echo -e "\e[31mOh hamburgers ... You forgot to add a JIRA issue number!\e[0m";
exit 1;

Method 2 – This is another very good example to implement to force jira id in each commit message. http://nsbogan.com/tools/2015/06/04/jira-id-in-git-commit-messages

The post Enforce the JIRA issue id in a GIT commit message appeared first on scmGalaxy.

Best Branching and Merging strategies in Gerrit

Step 1 – First Lets read this article about Best Branching and Merging strategies in git

Best Branching and Merging strategies in git

Step 2 – Now Lets learn the Gerrit Merge Types
https://nofluffjuststuff.com/magazine/2016/04/understanding_and_applying_gerrit_part_3_gerrit_submit_types_and_git_review

Step 3 – Time to Learn the Types of Submit in Gerrit
https://gerrit-review.googlesource.com/Documentation/project-configuration.html

Step 4 – Finally, You must read the recommendations below
https://hyperledger-fabric.readthedocs.io/en/release-1.2/Gerrit/best-practices.html

The post Best Branching and Merging strategies in Gerrit appeared first on scmGalaxy.

Best Branching and Merging strategies in git

Step 1 – First you need to learn the needs of branches. This is very good read.

• https://docs.microsoft.com/en-us/vsts/repos/tfvc/branching-strategies-with-tfvc?view=vsts

Step 2 – Now time has come to Learn best branching model in Git.

• https://buddy.works/blog/5-types-of-git-workflows
• https://hackernoon.com/a-branching-and-releasing-strategy-that-fits-github-flow-be1b6c48eca2
• https://nvie.com/posts/a-successful-git-branching-model/

Step 3 – Now, Lets understand, what is the kind of merges we have in Git?

• https://www.atlassian.com/git/tutorials/using-branches/git-merge
• https://git-scm.com/docs/merge-strategies
• https://stackoverflow.com/questions/366860/when-would-you-use-the-different-git-merge-strategies

Step 4 – Are you still having a questions, Please post in the comment section.

The post Best Branching and Merging strategies in git appeared first on scmGalaxy.

How to revert the changes once its submitted in Gerrit

The Revert button is available if the change has been submitted. This Reverts the change via creating a new one. When the Revert button is pressed, a panel will appear to allow the user to enter a commit message for the reverting change.

Once a revert change is created, the original author and any reviewers of the original change are added as reviewers and a message is posted to the original change linking to the revert.

However, patchsets can not be reverted. so first you have to checkout one of the previous patchset. you can get the command from Gerrit review board at each patchset download panel. After checking it out amend it to generate new commit hash then pushed again as a new patchset.

If I have multiple patch set versions for one change in Gerrit, You can only submit the latest patch set version. The design assumes that the most recent patch set is the one developers will review and test, and as such older patch sets can not be submitted.

Good Read
http://www.saros-project.org/node/155

The post How to revert the changes once its submitted in Gerrit appeared first on scmGalaxy.

Here is the short and quick description of Gerrit key teminology.

Change

Every time you push a commit with a new Change-Id Gerrit allocates a new change. Every change has a unique Change-Id and a Change Number. The change contains a number of patch sets, comments on the patch sets and a code review rating (+2, +1, 0, -1, -2). Each change has a dedicated page that shows information about it called individual change page. This includes dependencies between different changes, patch sets and the review comments.

Submit

Once a change has received a +2 in the Code Review and no negative voting in the other categories the last patchset can be submitted. This means Gerrit will now try to cherry-pick your patch set and mark the change as merged.

Patch set

If you want to modify your change, you don’t have to push a new change to Gerrit but only a new patch set . Imagine a patch sets as different versions or revisions of a change. Each patch set can receive inline comments. Gerrit uses the Change-Id of a commit message to identify patch sets of a change. This is why all patch sets of a change have the same Change-Id.

To create a new Patch when new changes are submitted
Step 1: Install commit-msg hooks for gerrit

$ scp -p -P 29418 localhost:hooks/commit-msg .git/hooks/

Step 2: Create normal commit and push (for Patchset1)

for example:

git add Server.java
git commit -m "server added"
git push origin HEAD:refs/for/master

Step 3: After doing some changes to Server.java

Finally to create new Patchset (Patchset 2)

git add Server.java
git commit --amend
git push origin HEAD:refs/for/master
Repeat step 3 for further Patches

Understanding the Patch set in Git perspective

Git is a very advanced distributed source code control system. Maintaining patch sets (often called a topic branch) in Git. Git includes a rebase capability that is very useful for a number of different operations related to maintaining a branch of code including moving a branch forward, moving a branch around on an upstream branch to look for breakage, and merging changesets to create patch files.

Git: How to create and apply patches

Creating a patch

Make your changes and commit them.
Run $ git format-patch COMMIT_REFERENCE #to convert all commits since the referenced commit (not including it) into patch files.
$ git format-patch HEAD~~

This will create 2 files, one for each commit since HEAD~~, like these:
0001-make-stuff-more-awesome.patch
0002-allow-users-to-be-locked.patch

Applying patches
You can use git apply some.patch to have the changes from the .patch file applied to your current working directory. They will be unstaged and need to be committed by you.

To apply a patch as a commit (with its commit message), use git am some.patch. \
For all patches to be applied, simply run:
$ git am *.patch

Note that in some previous version you could pass the latest patch filename of a list of patches to apply all previous patches as wel
$ git am 0002-allow-users-to-be-locked.patch # May no longer work for you

You then have the 2 unpushed commits from the patch file created earlier.

The post What is a Change and Patch set in Gerrit? appeared first on scmGalaxy.

How to replace Changes after the Gerrit review without changing the commit id?

One of the main benefits of code review is the ability to receive and incorporate feedback from other developers without changing the commit-id and review id. With Gerrit, you incorporate these changes by amending the commit. Gerrit uses the CHange-Id to ensure that each iteration of the commit are stored together as patchsets.

The process of modify same commit and commit message on gerrit after patchset creation is pretty straight forward.

Step 1 – Do the required modification in the code based on the review.

Step 2 – Add files using git add commands.

$ git add filename

Step 3 – Command to update/amend the most recent commit.

$ git commit --amend

When amending a commit with git commit –amend, leave the Change-Id line unmodified in the commit message. This will allow Gerrit to automatically update the change with the amended commit.

Step 4 – Gerrit updates the commit under review with your latest changes.

$ git push origin HEAD:refs/for/master
$ git push origin HEAD:refs/for/[BRANCH_NAME]

The post How to replace Changes after the Gerrit review without changing the commit id? appeared first on scmGalaxy.

Best practice says that before you commit in git, you need to either do git pull or git fetch/merge. However, there is a way to find out wheather your branches is not in sync with remote.

To check the remote repo status you are really simulating a “fetch”
$ git fetch -v –dry-run

To bring your remote refs up to date
$ git remote -v update

This command will print whether the branch you are tracking is ahead, behind or has diverged with remote. If it says nothing, the local and remote are the same.
$ git status -uno

To pull
$ git pull origin <<branchname>>
or
$ git fetch origin <<branchname>>
$ git merge remote/<<branchname>>
$ git commit

Compare the two branches:
$ git log HEAD..origin/master –oneline

The post How to update or pull current branch before committing in Git? appeared first on scmGalaxy.

There are 3 importants components to make sure Prometheus is up and running. We need to install and configure

1. Prometheus Server,
2. Node Exporter, and
3. Dashborad which can be PromDash or Grafana.

Step 1 – Install and configure Prometheus Server in RHEL 7

Download Prometheus
Download Prometheus from https://prometheus.io/download/. You can find 3 Prometheus package which is supported for darwin/linux and windows.

$ sudo -s
$ yum install wget -y
$ cd /opt/
$ wget https://github.com/prometheus/prometheus/releases/download/v2.3.2/prometheus-2.3.2.linux-amd64.tar.gz
$ tar -zxvf prometheus-2.3.2.linux-amd64.tar.gz
$ cd prometheus-2.3.2.linux-amd64

If you find following files….

[root@ip-172-31-21-164 prometheus-2.3.2.linux-amd64]# ls -1
LICENSE
NOTICE
console_libraries
consoles
prometheus
prometheus.yml
promtool

This completes the Prometheus installation.

Verify the installation by typing in the following command:

[root@ip-172-31-21-164 prometheus-2.3.2.linux-amd64]# ./prometheus --version
prometheus, version 2.3.2 (branch: HEAD, revision: 71af5e29e815795e9dd14742ee7725682fa14b7b)
build user: root@5258e0bd9cc1
build date: 20180712-14:02:52
go version: go1.10.3

Step 2 – Install and configure Prometheus Node Exporter in RHEL 7

In order to monitor the metrics of your RHEL server, you should install a tool called Node Exporter. Node Exporter, as its name suggests, exports lots of metrics (such as disk I/O statistics, CPU load, memory usage, network statistics, and more) in a format Prometheus understands.

cd /opt/
wget https://github.com/prometheus/node_exporter/releases/download/v0.16.0/node_exporter-0.16.0.linux-amd64.tar.gz
tar -zxvf node_exporter-0.16.0.linux-amd64.tar.gz
cd node_exporter-0.16.0.linux-amd64
nohup ./node_exporter &

Step 3 — Running Node Exporter as a Service
if you want to Running Node Exporter as a Service

$ sudo vi /etc/systemd/system/node_exporter.service

[Unit]
Description=Node Exporter
Wants=network-online.target
After=network-online.target

[Service]
User=root
Group=root
Type=simple
ExecStart=/root/prometheus/node_exporter/node_exporter

[Install]
WantedBy=multi-user.target

# Save the file and exit the text editor.

Reload systemd so that it reads the configuration file you just created.

$ sudo systemctl daemon-reload

Enable it so that it starts automatically at boot time.

$ sudo systemctl enable node_exporter.service

You can now either reboot your server, or use the following command to start the service manually:

$ sudo systemctl start node_exporter.service

Once it starts, use a browser to view Node Exporter’s web interface, which is available at http://your_server_ip:9100/metrics. You should see a page with a lot of text:

Step 4 — Starting Prometheus Server

Enter the directory where you installed the Prometheus server:

$ cd /opt/prometheus-2.3.2.linux-amd64

Before you start Prometheus, you must first understand a configuration file for it called prometheus.yml.

[root@ip-172-31-21-164 prometheus-2.3.2.linux-amd64]# more prometheus.yml
# my global config
global:
scrape_interval: 15s # Set the scrape interval to every 15 seconds. Default is every 1 minute.
evaluation_interval: 15s # Evaluate rules every 15 seconds. The default is every 1 minute.
# scrape_timeout is set to the global default (10s).

# Alertmanager configuration
alerting:
alertmanagers:
- static_configs:
- targets:
# - alertmanager:9093

# Load rules once and periodically evaluate them according to the global 'evaluation_interval'.
rule_files:
# - "first_rules.yml"
# - "second_rules.yml"

# A scrape configuration containing exactly one endpoint to scrape:
# Here it's Prometheus itself.
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'prometheus'

# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.

static_configs:
- targets: ['localhost:9090']

Whereas, This creates a scrape_configs section and defines a job called node. It includes the URL of your Node Exporter’s web interface in its array of targets. The scrape_interval is set to 15 seconds so that Prometheus scrapes the metrics once every fifteen seconds.

You could name your job anything you want, but calling it “node” allows you to use the default console templates of Node Exporter. Save the file and exit.

Start the Prometheus server as a background process.

$ nohup ./prometheus > prometheus.log 2>&1 &

You can view the last few lines of the file using the tail command:

$ tail prometheus.log

Once the server is ready, you will see the following messages in the file:

level=info ts=2018-08-21T11:47:38.56459183Z caller=web.go:415 component=web msg="Start listening for connections" address=0.0.0.0:9090
level=info ts=2018-08-21T11:47:38.569742672Z caller=main.go:543 msg="TSDB started"
level=info ts=2018-08-21T11:47:38.569767659Z caller=main.go:603 msg="Loading configuration file" filename=prometheus.yml
level=info ts=2018-08-21T11:47:38.57069388Z caller=main.go:629 msg="Completed loading of configuration file" filename=prometheus.yml
level=info ts=2018-08-21T11:47:38.570724527Z caller=main.go:502 msg="Server is ready to receive web requests."

Use a browser to visit Prometheus’s homepage available at http://your_server_ip:9090. You’ll see the following homepage.

Step 5 — Verify Prometheus Server
To make sure that Prometheus server is scraping data from Node Exporter, click on the Graph tab at the top of the page. On the page that opens, type in the name of a metric (like up, for example) in the text field that says Expression. Then, press the blue Execute button. Click Graph (next to Console) just below, and you should see a graph for that metric:

More metric can be found from the Node Exporter host such as
http://X.X.X.X:9100/metrics

Prometheus has console templates that let you view graphs of a few commonly used metrics. These console template are accessible only if you set the value of job_name to “prometheus” in Prometheus’s configuration.

Visit http://your_server_ip:9090/consoles/prometheus.html to access the Node Console and click on your server, localhost:9100, to view its metrics.

Step 6 — Installing PromDash Or Grafana…..

The post Install and Configure Prometheus Server and Node Exporter in RHEL appeared first on scmGalaxy.

Step 1 – Download & Install Grafana
Download Grafana RPM file RPM for Linux from https://grafana.com/grafana/download?platform=linux

# Ubuntu & Debian
$ wget https://s3-us-west-2.amazonaws.com/grafana-releases/release/grafana_5.2.2_amd64.deb
$ sudo dpkg -i grafana_5.2.2_amd64.deb

Step 2 – Understand Grafana Installation details in Ubuntu/Debian

1. Installs binary to /usr/sbin/grafana-server
2. Installs Init.d script to /etc/init.d/grafana-server
3. Creates default file (environment vars) to /etc/default/grafana-server
4. Installs configuration file to /etc/grafana/grafana.ini
5. Installs systemd service (if systemd is available) name grafana-server.service
6. The default configuration sets the log file at /var/log/grafana/grafana.log
7. The default configuration specifies an sqlite3 db at /var/lib/grafana/grafana.db
8. Installs HTML/JS/CSS and other Grafana files at /usr/share/grafana

Step 3 – Start the server (init.d service)

$ sudo service grafana-server start

This will start the grafana-server process as the grafana user, which was created during the package installation. The default HTTP port is 3000 and default user and group is admin.

Step 4 – Configure the Grafana server to start at boot time

$ sudo update-rc.d grafana-server defaults
$ systemctl daemon-reload
$ systemctl start grafana-server
$ systemctl status grafana-server
$ sudo systemctl enable grafana-server.service

Step 5 – Grafana server Environment file
The systemd service file and init.d script both use the file located at /etc/default/grafana-server for environment variables used when starting the back-end. Here you can override log directory, data directory and other variables.

Step 6 – Grafana server Log
By default Grafana will log to /var/log/grafana

Step 7 – Grafana Database
The default configuration specifies a sqlite3 database located at /var/lib/grafana/grafana.db.

You can also use MySQL or Postgres as the Grafana database, as detailed on
http://docs.grafana.org/installation/configuration/#database

Step 7 – Grafana configuration
The configuration file is located at /etc/grafana/grafana.ini. Go the Configuration page for details on all those options. You can add following data sources

1. Graphite
2. InfluxDB
3. OpenTSDB
4. Prometheus

Step 8 – Server side image rendering
Server side image (png) rendering is a feature that is optional but very useful when sharing visualizations, for example in alert notifications.

$ yum install fontconfig
$ yum install freetype*
$ yum install urw-fonts

Step 9 – How to access the Grafana dashboard

http://13.232.27.156:3000/
User name – admin
Password – admin

The post Install and Configure Grafana in Ubuntu and Debian appeared first on scmGalaxy.

Step 1 – Download & Install Grafana
Download Grafana RPM file RPM for Linux from https://grafana.com/grafana/download?platform=linux

# RHEL 7

$ sudo yum install initscripts fontconfig -y
$ wget https://s3-us-west-2.amazonaws.com/grafana-releases/release/grafana-5.2.2-1.x86_64.rpm
$ sudo yum localinstall grafana-5.2.2-1.x86_64.rpm

Step 2 – Understand Grafana Installation details in RHEL/CENTOS

1. Installs binary to /usr/sbin/grafana-server
2. Copies init.d script to /etc/init.d/grafana-server
3. Installs default file (environment vars) to /etc/sysconfig/grafana-server
4. Copies configuration file to /etc/grafana/grafana.ini
5. Installs systemd service (if systemd is available) name grafana-server.service
6. The default configuration uses a log file at /var/log/grafana/grafana.log
7. The default configuration specifies an sqlite3 database at /var/lib/grafana/grafana.db

Step 3 – Start the server (init.d service)

$ sudo service grafana-server start

This will start the grafana-server process as the grafana user, which is created during package installation. The default HTTP port is 3000, and default user and group is admin.

Step 4 – Configure the Grafana server to start at boot time

$ sudo /sbin/chkconfig --add grafana-server
$ sudo systemctl enable grafana-server.service
$ systemctl daemon-reload
$ systemctl start grafana-server
$ systemctl status grafana-server

Step 5 – Grafana server Environment file
The systemd service file and init.d script both use the file located at /etc/sysconfig/grafana-server for environment variables used when starting the back-end. Here you can override log directory, data directory and other variables.

Step 6 – Grafana server Log
By default Grafana will log to /var/log/grafana

Step 7 – Grafana Database
The default configuration specifies a sqlite3 database located at /var/lib/grafana/grafana.db. Please backup this database before upgrades.

You can also use MySQL or Postgres as the Grafana database, as detailed on
http://docs.grafana.org/installation/configuration/#database

Step 8 – Grafana configuration
The configuration file is located at /etc/grafana/grafana.ini. Go the Configuration page for details on all those options. You can add following data sources

1. Graphite
2. InfluxDB
3. OpenTSDB
4. Prometheus

Step 9 – Server side image rendering
Server side image (png) rendering is a feature that is optional but very useful when sharing visualizations, for example in alert notifications.

$ sudo yum install fontconfig -y
$ sudo yum install freetype* -y
$ sudo yum install urw-fonts -y

Step 10 – Browse the dashboard
http://X.X.X.X.:3000/
Username – admin
Password – admin

The post Install and Configure Grafana in RHEL 7 appeared first on scmGalaxy.

1. Native Docker
2. cAdvisor
3. Scout
4. Pingdom
5. Datadog
6. Sysdig
7. Prometheus
8. Heapster / Grafana
9. ELK stack
10. Sensu

Reference

https://rancher.com/comparing-10-container-monitoring-solutions-rancher/

The post Top 10 Container(Docker) Monitoring Solutions and Tools in 2018 appeared first on scmGalaxy.