Monday, July 24, 2017

yarn application stops when uid is too low


hi all,

Just want to share the experience when the min.user.id has not changed by default, no yarn application could be submitted. Usually, you will have something like below.

Diagnostics: Application application_1500628462670_0096 initialization failed (exitCode=255) with output: main : command provided 0
main : run as user is hiuy
main : requested yarn user is hiuy
Requested user hiuy is not whitelisted and has id 501,which is below the minimum allowed 1000

Failing this attempt. Failing the application.
 ApplicationMaster host: N/A
 ApplicationMaster RPC port: -1
 queue: root.users.hiuy
 start time: 1500632228942
 final status: FAILED
 user: hiuy
I2017-07-21 06:17:10,181 Client:[ForkJoinPool-1-worker-3] Deleted staging directory hdfs://ip-172-31-16-195.ap-southeast-1.compute.internal:8020/user/hiuy/.sparkStaging/application_1500628462670_0096
E2017-07-21 06:17:10,185 SparkContext:[ForkJoinPool-1-worker-3] Error initializing SparkContext.
org.apache.spark.SparkException: Yarn application has already ended! It might have been killed or unable to launch application master.
at org.apache.spark.scheduler.cluster.YarnClientSchedulerBackend.waitForApplication(YarnClientSchedulerBackend.scala:85) ~[spark-yarn_2.11-2.1.1.jar:2.1.1]
at org.apache.spark.scheduler.cluster.YarnClientSchedulerBackend.start(YarnClientSchedulerBackend.scala:62) ~[spark-yarn_2.11-2.1.1.jar:2.1.1]
at org.apache.spark.scheduler.TaskSchedulerImpl.start(TaskSchedulerImpl.scala:156) ~[spark-core_2.11-2.1.1.jar:2.1.1]
at org.apache.spark.SparkContext.(SparkContext.scala:509) ~[spark-core_2.11-2.1.1.jar:2.1.1]
at org.apache.spark.SparkContext$.getOrCreate(SparkContext.scala:2320) [spark-core_2.11-2.1.1.jar:2.1.1]
at org.apache.spark.sql.SparkSession$Builder$$anonfun$6.apply(SparkSession.scala:868) [spark-sql_2.11-2.1.1.jar:2.1.1]


In order to solve the problem, you could either bump up the UID for the yarn application user to any integer value that above 1000, or you could set the min.user.id at YARN configuration. Make sure that you need to restart YARN when after the configuration alteration is done.

Hope that helps. Thanks!

Thursday, July 13, 2017

Python code: python acting like awk

hi all,

I am really love to use unix utility such as "awk". It is useful when I wish to retrieve a certain column in a delimited file, e.g. /etc/passwd. I believe everyone should know. It is simple and easy.

root@lynx-vm:~# cat /etc/passwd | awk -F":" '{print $1}'
root
daemon
bin
sys
sync
games
man
lp
mail
news
uucp
proxy


However, I would like to show you on how to get it done with Python. Personally, I have struggled a lot when doing a similar operation in unix command, as compared in Python. Hope that small tricks could save your times.

>>>
>>>
>>> passwdlines = [ line.split(":") for line in open("/etc/passwd") if "#" not in line]
>>> passwdlines[:5]
[['root', 'x', '0', '0', 'root', '/root', '/bin/bash\n'], ['daemon', 'x', '1', '1', 'daemon', '/usr/sbin', '/usr/sbin/nologin\n'], ['bin', 'x', '2', '2', 'bin', '/bin', '/usr/sbin/nologin\n'], ['sys', 'x', '3', '3', 'sys', '/dev', '/usr/sbin/nologin\n'], ['sync', 'x', '4', '65534', 'sync', '/bin', '/bin/sync\n']]
>>> 


If you would like to know the first column.
>>>
>>> firstcolumn = [column[0] for column in passwdlines]
>>>
>>>
>>> firstcolumn[:5]
['root', 'daemon', 'bin', 'sys', 'sync']
>>> 


If you would like to know the line contains "root".
>>>
>>> rootline = [ line for line in passwdlines if "root" in line]
>>>
>>>
>>> rootline
[['root', 'x', '0', '0', 'root', '/root', '/bin/bash\n']]

Wednesday, July 12, 2017

Python code: Calculating stack of balanced brackets in a string

Hi

I am solving the problem of a string of brackets, to detect if the string of brackets are matching and balanced. e.g. a string like following:


[]][{]{(({{)[})(}[[))}{}){[{]}{})()[{}]{{]]]){{}){({(}](({[{[{)]{)}}}({[)}}([{{]]({{
or 
(}{(()[][[){{}{{[}][]{{{{[{{[](}{)}](}}()]}(}(}}]}[](]]){{{()}({[[}}{{[]}(]}{(]{}}[()(}]{[[]{){{

I felt this is something fun and challenging to do. if you have good and creative answers, or detecting my code is buggy for some cases please keep me posted. Thanks!

def is_matched(expression):
    DictBracket = {"{":"}", "[":"]", "(":")"}
    OpenBracket = []
    for counter, char in iter(enumerate(expression)):
        if char in DictBracket.keys():
            OpenBracket.append(char)
        else:
            if counter == 0 and char not in DictBracket.keys():
                return False            
            if counter > 0 and char in DictBracket.values():
                if len(OpenBracket) and DictBracket[OpenBracket.pop()] in char:
                    continue                
            else:
                    return False    
     return len(OpenBracket) == 0
expression = input().strip()
if is_matched(expression) == True:
 print("YES")
else:
 print("NO")

Wednesday, March 22, 2017

HDFS Explorer

Hi all,

Hadoop HDFS command is good. But somehow it becomes hair-wired when we have a long arguments inputs. Those are error-prone and tedious to structure one. So with this notion of in mind, I just developed a wrapper script to facilitate this operation. Easy to install, easy to use too. Here is more descriptions and details about the tool.

Thank you.

https://github.com/yenonn/hdfs-explorer

Example of the output:

Hadoop explorer
HDFS > ls /
 * Running: hdfs dfs -ls /

Found 4 items
drwxr-xr-x   - hdfs supergroup          0 2016-12-01 11:56 /system
drwxr-xr-x   - kite kite                0 2015-11-04 16:36 /testing
drwxrwxrwt   - hdfs supergroup          0 2017-03-23 11:00 /tmp
drwxr-xr-x   - hdfs supergroup          0 2016-02-19 16:17 /user


Thursday, December 1, 2016

Cloudera HDFS kerberized failure: GSSException No Valid credentials

hi hadooper,

This is the problem that you will be facing once you have enabled kerberos on a cloudera server.

Here are the log of the hadoop looks like:

2016-12-01 20:28:21,650 INFO org.apache.hadoop.ipc.Server: Socket Reader #1 for port 8022: readAndProcess from client 172.31.6.120 threw exception [javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)]]
2016-12-01 20:28:23,457 INFO org.apache.hadoop.ipc.Server: Socket Reader #1 for port 8022: readAndProcess from client 172.31.0.159 threw exception [javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)]]
2016-12-01 20:28:23,627 INFO org.apache.hadoop.ipc.Server: Socket Reader #1 for port 8022: readAndProcess from client 172.31.0.158 threw exception [javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism level: Encryption type AES256 CTS mode with HMAC SHA1-96 is not supported/enabled)]]

The quick remedy on this will be applying the Java Cryptograhy Extension (JCE) on all the nodes in the cluster.

Here is the step to apply the JCE jar files.

1. Download the tarball which contents the following jar files.

US_export_policy.jar
local_policy.jar

2. Copying them onto each nodes, and overwrite the existing jar files.

/usr/java/jdk1.7.0_67-cloudera/jre/lib/security/US_export_policy.jar
/usr/java/jdk1.7.0_67-cloudera/jre/lib/security/local_policy.jar

3. Make sure, the permission and ownership of the files are retained.

4. Restart hadoop HDFS services.

5. Verify the log file, if there are the same logs appears as before: /var/log/hadoop-hdfs/*

6. Verify your kerberized HDFS is working properly.

[root@ip-172-31-0-157 ~]# kinit cloudera-scm/admin
Password for cloudera-scm/admin@EXAMPLE.COM:
[root@ip-172-31-0-157 ~]# hadoop fs -ls /
Found 1 items
drwxrwxrwt   - hdfs supergroup          0 2016-11-30 21:59 /tmp

7. If you wish to increase the verbosity of the output, you can always export the environment e.g.

export HADOOP_OPTS="-Dsun.security.krb5.debug=true"

8. If you wish to renew the token ticket

kinit -R

9. The krb client configuration /etc/krb5.conf is also important to specific the type e.g. otherwise, you will have this type of errors.

[root@ip-172-31-11-158 197-hdfs-NAMENODE]# cat /etc/krb5.conf
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_kdc = false
dns_lookup_realm = false
ticket_lifetime = 86400
renew_lifetime = 604800
forwardable = true
default_tgs_enctypes = rc4-hmac
default_tkt_enctypes = rc4-hmac
permitted_enctypes = rc4-hmac
udp_preference_limit = 1
kdc_timeout = 3000
[realms]
EXAMPLE.COM = {
kdc = ip-172-31-25-156.ap-southeast-1.compute.internal
admin_server = ip-172-31-25-156.ap-southeast-1.compute.internal
}

[root@ip-172-31-25-156 ~]# hadoop fs -ls /
Java config name: null Native config name: /etc/krb5.conf
Loaded from native config
>>>KinitOptions cache name is /tmp/krb5cc_0
>>>DEBUG  client principal is hiuy@EXAMPLE.COM
>>>DEBUG server principal is krbtgt/EXAMPLE.COM@EXAMPLE.COM
>>>DEBUG key type: 18
>>>DEBUG auth time: Fri Dec 02 03:42:32 EST 2016
>>>DEBUG start time: Fri Dec 02 03:42:32 EST 2016
>>>DEBUG end time: Sat Dec 03 03:42:32 EST 2016
>>>DEBUG renew_till time: Fri Dec 02 03:42:32 EST 2016
>>> CCacheInputStream: readFlags()  FORWARDABLE; RENEWABLE; INITIAL;
>>>DEBUG  client principal is hiuy@EXAMPLE.COM
>>>DEBUG server principal is X-CACHECONF:/krb5_ccache_conf_data/fast_avail/krbtgt/EXAMPLE.COM@EXAMPLE.COM
>>>DEBUG key type: 0
>>>DEBUG auth time: Wed Dec 31 19:00:00 EST 1969
>>>DEBUG start time: null
>>>DEBUG end time: Wed Dec 31 19:00:00 EST 1969
>>>DEBUG renew_till time: null
>>> CCacheInputStream: readFlags()
>>> unsupported key type found the default TGT: 18
16/12/02 04:23:11 WARN security.UserGroupInformation: PriviledgedActionException as:root (auth:KERBEROS) cause:javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
16/12/02 04:23:11 WARN ipc.Client: Exception encountered while connecting to the server : javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]
16/12/02 04:23:11 WARN security.UserGroupInformation: PriviledgedActionException as:root (auth:KERBEROS) cause:java.io.IOException: javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)]

Friday, August 12, 2016

HDFS HA failover script


hi,

Assuming that you have HDFS HA enabled, then you can have it done. Compiling small HDFS utility to do the failover by handy. Enjoy... :)

#!/bin/bash

SUHDFS="sudo -u hdfs hdfs"

nameservice=`$SUHDFS getconf -confKey dfs.nameservices`

echo "Nameservice: $nameservice"

serviceIds=`$SUHDFS getconf -confKey dfs.ha.namenodes.$nameservice | sed -s 's|,| |g'`
state=""
is_active=""
is_standby=""
for Id in `echo $serviceIds`
do
        namenode_hostname=`$SUHDFS getconf -confKey dfs.namenode.rpc-address.$nameservice.$Id`
        state=`$SUHDFS haadmin -getServiceState $Id`
        if [ "$state" == "active" ]
        then
                is_active="$Id"
        fi
        if [ "$state" == "standby" ]
        then
                is_standby="$Id"
        fi

        echo "Hostname : $namenode_hostname"
        echo "Service ID: $Id ($state)"
done

echo ""
echo -n "Do you want to do a failover from $is_active (active) -> $is_standby (standby)?: [y/n]"
read ans

if [ "$ans" = "y" ]
then
        echo " >> failing over now ...."
        echo " Executing >>hdfs haadmin -failover $is_active $is_standby"
        $SUHDFS haadmin -failover $is_active $is_standby
        if [ "$?" == "0" ]
        then
                echo " >> Done"
        else
                echo " >> Failed"
        fi
else
        echo ">> Exitting ..."
fi

Here is the result.

[root@ip-172-31-17-185 ~]# ./haadmin.sh
Nameservice: nameservice1
Hostname : ip-172-31-17-183.ap-southeast-1.compute.internal:8020
Service ID: namenode22 (standby)
Hostname : ip-172-31-17-184.ap-southeast-1.compute.internal:8020
Service ID: namenode37 (active)

Do you want to do a failover from namenode37 (active) -> namenode22 (standby)?: [y/n]y
 >> failing over now ....
 Executing >>hdfs haadmin -failover namenode37 namenode22
Failover to NameNode at ip-172-31-17-183.ap-southeast-1.compute.internal/172.31.17.183:8022 successful
 >> Done
[root@ip-172-31-17-185 ~]# ./haadmin.sh
Nameservice: nameservice1
Hostname : ip-172-31-17-183.ap-southeast-1.compute.internal:8020
Service ID: namenode22 (active)
Hostname : ip-172-31-17-184.ap-southeast-1.compute.internal:8020
Service ID: namenode37 (standby)

Do you want to do a failover from namenode22 (active) -> namenode37 (standby)?: [y/n]n
>> Exitting ...

Wednesday, August 10, 2016

Installing Python3.5 on CENTOS 6.8

hi all,

I would like to list down all the steps to do a upgrade for python 3.5 on CENTOS6.8.

1. Installing the prerequisite package to build python from source

yum -y groupinstall "Development tools"


yum -y install zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel gdbm-devel db4-devel libpcap-devel xz-devel 

2. Download the python source.


tar xvfz Python-3.5.*.tgz

cd Python-3.5.*

3. Compiling the python from source


./configure --prefix=/usr/local --enable-shared LDFLAGS="-Wl,-rpath /usr/local/lib"

make && make altinstall

ln -s /usr/local/bin/python3.5 /usr/bin/python3.5

4. Download and install the pip 



python3.5 get-pip.py

ln -s /usr/local/bin/pip /usr/bin/pip  

5. Voila, you have python3.5 ready.

[root@ip-172-31-18-184 ec2-user]# python3.5
Python 3.5.2 (default, Aug 10 2016, 23:27:34)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-17)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

6. Pip is ready too

[root@ip-172-31-18-184 ec2-user]# pip --version
pip 8.1.2 from /usr/local/lib/python3.5/site-packages (python 3.5)

Hope it helps.

Tuesday, August 9, 2016

Exploration on Cloudera: managing services without Cloudera Manager

hi,

Cloudera hadoop ecosystem product is a wonderful project that ever been created. Some or many of the engineers thought and curious on the way how Cloudera in controlling hadoop processes, e.g. how to start/stop a NameNode, ResourceManager, etc services without actually login to Cloudera Manager portal. Actually, I like the way how Cloudera engineer the solution. The core of the technology is supervisord. For more detail explanation, you can visit the website at Cloudera documentation website (https://www.cloudera.com/documentation/enterprise/5-4-x/topics/cm_intro_primer.html).

Bottom line of this post is about sharing my findings about the how to control the hadoop processes e.g. start/stop/status through the command lines, but not from the web portal.

I am assuming that you have a up and running cloudera hadoop cluster installed. I have installed a bare minimal hadoop cluster products, which including zookeeper, HDFS, and YARN. I have it done on the aws cloud, 4 x mx4.xlarge instances . That's all.

To start with, I will explore the role of  a node.

[root@ip-172-31-17-183 ec2-user]# jps
2572 NameNode
2669 ResourceManager
3562 Jps

From here, I know this node is serving as for a NameNode and ResourceManager. That's beautiful. To dig further into the running processes. e.g. ResourceManager Pid. What caught my attention is the line that I have highlighted, /var/run/cloudera-scm-agent/process/59-yarn-RESOURCEMANAGER.  

/usr/java/jdk1.7.0_67-cloudera/bin/java -Dproc_resourcemanager -Xmx1000m -Djava.net.preferIPv4Stack=true -Xms1073741824 -Xmx1073741824 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -XX:+CMSParallelRemarkEnabled -Dhadoop.event.appender=,EventCatcher -XX:OnOutOfMemoryError=/usr/lib64/cmf/service/common/killparent.sh -Dhadoop.log.dir=/var/log/hadoop-yarn -Dyarn.log.dir=/var/log/hadoop-yarn -Dhadoop.log.file=hadoop-cmf-yarn-RESOURCEMANAGER-ip-172-31-17-183.ap-southeast-1.compute.internal.log.out -Dyarn.log.file=hadoop-cmf-yarn-RESOURCEMANAGER-ip-172-31-17-183.ap-southeast-1.compute.internal.log.out -Dyarn.home.dir=/opt/cloudera/parcels/CDH-5.8.0-1.cdh5.8.0.p0.42/lib/hadoop-yarn -Dhadoop.home.dir=/opt/cloudera/parcels/CDH-5.8.0-1.cdh5.8.0.p0.42/lib/hadoop-yarn -Dhadoop.root.logger=INFO,RFA -Dyarn.root.logger=INFO,RFA -Djava.library.path=/opt/cloudera/parcels/CDH-5.8.0-1.cdh5.8.0.p0.42/lib/hadoop/lib/native -classpath /var/run/cloudera-scm-agent/process/59-yarn-RESOURCEMANAGER:/var/run/cloudera-scm-agent/process/59-yarn-RESOURCEMANAGER:/var/run/cloudera-scm-agent/process/59-yarn-RESOURCEMANAGER:/opt/cloudera/parcels/CDH-5.8.0-1.cdh5.8.0.p0.42/lib/hadoop/lib/*:/opt/cloudera/parcels/CDH-5.8.0-1.cdh5.8.0.p0.42/lib/hadoop/.//*:/opt/cloudera/parcels/CDH-5.8.0-1.cdh5.8.0.p0.42/lib/hadoop-hdfs/./:/opt/cloudera/parcels/CDH-5.8.0-1.cdh5.8.0.p0.42/lib/hadoop-hdfs/lib/*:/opt/cloudera/parcels/CDH-5.8.0-1.cdh5.8.0.p0.42/lib/hadoop-hdfs/.//*:/opt/cloudera/parcels/CDH-5.8.0-1.cdh5.8.0.p0.42/lib/hadoop-yarn/lib/*:/opt/cloudera/parcels/CDH-5.8.0-1.cdh5.8.0.p0.42/lib/hadoop-yarn/.//*:/opt/cloudera/parcels/CDH-5.8.0-1.cdh5.8.0.p0.42/lib/hadoop-mapreduce/lib/*:/opt/cloudera/parcels/CDH-5.8.0-1.cdh5.8.0.p0.42/lib/hadoop-mapreduce/.//*:/usr/share/cmf/lib/plugins/tt-instrumentation-5.8.1.jar:/usr/share/cmf/lib/plugins/event-publish-5.8.1-shaded.jar:/opt/cloudera/parcels/CDH-5.8.0-1.cdh5.8.0.p0.42/lib/hadoop-yarn/.//*:/opt/cloudera/parcels/CDH-5.8.0-1.cdh5.8.0.p0.42/lib/hadoop-yarn/lib/*:/var/run/cloudera-scm-agent/process/59-yarn-RESOURCEMANAGER/rm-config/log4j.properties org.apache.hadoop.yarn.server.resourcemanager.ResourceManager

Also, from the pstree output I know that ResourceManager is not started up with a classic system daemon. There is a python script that actually forking the processes.

`-python-+-python2.6
              |-python2.6---5*[{python2.6}]
              |-java---107*[{java}]
              `-java---213*[{java}]

  |-python /usr/lib64/cmf/agent/build/env/bin/supervisord
  |   |-java -Dproc_resourcemanager -Xmx1000m -Djava.net.preferIPv4Stack=true-
  |   |   |-{java}
  |   |   |-{java}

Yes! that's the supervisord that I am expecting. I am too curious on the /var/run/cloudera-scm-agent/ too. So, I did an exploration and dig in at the directory to find out what could we have.

Surprise..surprise....there is a supervisord.conf configuration within the directory,

[root@ip-172-31-17-183 supervisor]# cat /var/run/cloudera-scm-agent/supervisor/supervisord.conf
[unix_http_server]
file=%(here)s/supervisord.sock
username=6434554715077552454
password=8561047171289009924

[inet_http_server]
port=127.0.0.1:19001
username=6434554715077552454
password=8561047171289009924

[supervisord]
nodaemon=false
logfile=/var/log/cloudera-scm-agent/supervisord.log
identifier=agent-1626-1470791793

[include]
files = /var/run/cloudera-scm-agent/supervisor/include/*.conf

[supervisorctl]
serverurl=http://127.0.0.1:19001/
username=6434554715077552454
password=8561047171289009924

Aha! Now, I know there is a port opening and listening at 19001, it has the credentials that listed in it. Also, it includes all the sub conf files sharing with other daemons. I am satisfying, indeed. Now, I want to know more on the port and the web ui of the supervisord/supervisorctl. 

For sure, I know there is a port that listening at 19001 at localhost. Perfect!

[root@ip-172-31-17-183 supervisor]# netstat -atun | grep 19001
tcp        0      0 127.0.0.1:19001             0.0.0.0:*                   LISTEN
tcp        0      0 127.0.0.1:41185             127.0.0.1:19001             ESTABLISHED
tcp        0      0 127.0.0.1:19001             127.0.0.1:41185             ESTABLISHED

Now, I just need to expose the localhost to external by SSH tunnelling. That's easy, just passing the hightlight line when you are login. 

MacBook-Pro:Downloads yenonn$ ssh -i hadoop.pem -L19001:localhost:19001 ec2-user@ec2-54-179-147-37.ap-southeast-1.compute.amazonaws.com
Last login: Tue Aug  9 21:21:18 2016 from 223.197.191.42
-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory
[ec2-user@ip-172-31-17-183 ~]$

And I am ready to explore more supervisorctl web ui from my browser. Beautiful! It means I can startup hadoop services from here. pretty neat!

If lets say, you are not a big fan of web ui. We can make use of supervisorctl to achieve the same purpose.

[root@ip-172-31-17-183 supervisor]# /usr/lib64/cmf/agent/build/env/bin/supervisorctl
49-cloudera-mgmt-SERVICEMONITOR  RUNNING    pid 5526, uptime 0:03:36
53-hdfs-NAMENODE                 RUNNING    pid 2572, uptime 0:32:13
59-yarn-RESOURCEMANAGER          RUNNING    pid 2669, uptime 0:32:13
cmflistener                      RUNNING    pid 1801, uptime 0:32:18
flood                            RUNNING    pid 1991, uptime 0:32:16

I can make sure of the supervisord.conf to start/stop the services from here.

[root@ip-172-31-17-183 supervisor]# /usr/lib64/cmf/agent/build/env/bin/supervisorctl -c /var/run/cloudera-scm-agent/supervisor/supervisord.conf status
49-cloudera-mgmt-SERVICEMONITOR  RUNNING    pid 5526, uptime 0:05:01
53-hdfs-NAMENODE                 RUNNING    pid 2572, uptime 0:33:38
59-yarn-RESOURCEMANAGER          RUNNING    pid 2669, uptime 0:33:38
cmflistener                      RUNNING    pid 1801, uptime 0:33:43
flood                            RUNNING    pid 1991, uptime 0:33:41

[root@ip-172-31-17-183 supervisor]# /usr/lib64/cmf/agent/build/env/bin/supervisorctl -c /var/run/cloudera-scm-agent/supervisor/supervisord.conf stop 49-cloudera-mgmt-SERVICEMONITOR
49-cloudera-mgmt-SERVICEMONITOR: stopped

[root@ip-172-31-17-183 supervisor]# /usr/lib64/cmf/agent/build/env/bin/supervisorctl -c /var/run/cloudera-scm-agent/supervisor/supervisord.conf start 49-cloudera-mgmt-SERVICEMONITOR
49-cloudera-mgmt-SERVICEMONITOR: started


Hope you like it. I love Cloudera and will continue to do my exploration!!

Monday, June 13, 2016

Graphite-web in container

hi all,

I am trying to separate each of the components of graphite engines into a small pieces such that it is agile and easy to duplicate when you need to scale out. I have built my first graphite-web container and contributed to github. I will continue to work on the carbon-cache Dockerfile and others components.

Graphite-web: https://github.com/yenonn/docker-graphite

Thursday, June 9, 2016

Setting up a graphite service in CENTOS 7.2

hi all,

I just want list down the steps of graphite installation on CENTOS7.2.


First you have to install the pre-requisite of the packages.

1. yum -y install epel-release python-pip python-devel gcc libev libev-devel pycairo rrdtool-python mod_wsgi git httpd


2. pip install django==1.8.13 carbon whisper graphite-web django-tagging pytz


3. pip install twisted --upgrade


4. chmod a+w /opt/graphite/storage


Start copying the conf files and make changes.

5. cp /opt/graphite/conf/carbon.conf.example /opt/graphite/conf/carbon.conf

6. cp /opt/graphite/conf/graphite.wsgi.example /opt/graphite/conf/graphite.wsgi


7. cp /opt/graphite/conf/storage-schemas.conf.example /opt/graphite/conf/storage-schemas.conf

8. cp /opt/graphite/webapp/graphite/local_settings.py.example /opt/graphite/webapp/graphite/local_settings.py 

Once you are done with the copying local_settings.py, please update that TIME_ZONE and SECRET_KEY. please use the tzselect if you don't know how to set your time zone. Secret key can be any strings that you can think of.

Now you are start working on your apache setting.

9. cp /opt/graphite/examples/example-graphite-vhost.conf /etc/httpd/conf.d/graphite-vhost.conf


Here is how the lines in graphite-vhost.conf should look like in Alias /content/ and Directory of /opt/graphite/conf





















Comment out the extra mod_wsgi mod from another conf file.

10. cat /etc/httpd/conf.modules.d/10-wsgi.conf

#LoadModule wsgi_module modules/mod_wsgi.so



On the default /etc/httpd/conf/httpd.conf, you have to update the ServerName. After all you can start your web server service.

11. ServerName  localhost:80


12. setenforce 0; systemctl enable httpd.service; systemctl start httpd.service


Now you can start initialise your django framework. Please complete all the questions asked during the initial setup. Put in your admin credential and email.

13. python /opt/graphite/webapp/graphite/manage.py migrate auth


14. python /opt/graphite/webapp/graphite/manage.py syncdb


Now you can start working on the carbon daemon and start it. 

15. python /opt/graphite/bin/carbon-cache.py start


Next you will need to verify your carbon port is listening and your web port is running.

16. netstat -atun | grep 2003
tcp        0      0 0.0.0.0:2003                0.0.0.0:*                   LISTEN

17. netstat -atun | grep 80
tcp        0      0 0.0.0.0:80                0.0.0.0:*                   LISTEN


Wait for a while, after you have started the services. You need to look into your graphite storage for any new whisper file been created. Keep prompt the directory for any new created whisper files.


18. [root@localhost ~]# find /opt/graphite/storage/ -name *.wsp

/opt/graphite/storage/whisper/carbon/agents/localhost_localdomain-a/cache/size.wsp
/opt/graphite/storage/whisper/carbon/agents/localhost_localdomain-a/cache/queries.wsp
/opt/graphite/storage/whisper/carbon/agents/localhost_localdomain-a/cache/bulk_queries.wsp
/opt/graphite/storage/whisper/carbon/agents/localhost_localdomain-a/cache/queues.wsp
/opt/graphite/storage/whisper/carbon/agents/localhost_localdomain-a/cache/overflow.wsp

/opt/graphite/storage/whisper/carbon/agents/localhost_localdomain-a/memUsage.wsp



Once all done, your graphite should be up and running. you can open your browser and go to your graphite web service to verify it is running. At this moment, you should not seeing any data injection from any servers yet. you need to continue working on collectd installation on the client nodes.