0:00
Hello and welcome to Edge Management Infrastructure operation.
In this video, we will explore open source component management,
Apache Cassandra, Apache ZooKeeper,
Apache Qpid, and talked briefly about other components.
Let's get started with open source component management.
Apigee leverages multiple leading open source technologies to create Edge.
In all cases, we never modify the actual open source software.
If we find a fix or improvement, typically,
we work with the open source community and contribute that way.
Online documentation that exists for any of the components shown,
as well as any third-party tools from management,
will be compatible with Apigee open source technology distributions.
This includes Cassandra, Zookeeper,
PostgreSQL, OpenLDAP, and Qpid.
Our first open source component is Apache Cassandra,
and specifically, the Nodetool command.
Nodetool is an administration utility provided by Cassandra,
and is located in /opt/apigee/apigee-cassandra/bin.
The tool uses a general format, nodetool,
then specify the host on which to perform the action, and then the command to run.
And all these examples were run in the command,
with minus h0, which means the local host.
First command, nodetool ring,
this shows the status of the Cassandra ring,
as seen from the perspective of the node being queried.
If your cluster is incorrectly configured,
you may see different outputs if you run the command on different nodes.
Nodetool status, as per nodetool ring,
this provides information about the cluster,
such as state, load, token range,
data ownership, rack information,
and IDs of member nodes.
Nodetool compaction stats, this shows
the name of any SS tables currently being compacted,
the progress of each compaction event, and the time remaining.
This is useful if you need to confirm whether
observed high disk I/O is being caused by compaction events or other factors.
Nodetool info, this provides information for a single node,
such as token and storage information,
as well as uptime and heap memory usage.
Nodetool gossipinfo, this does exactly what it says,
it provides gossip information for the cluster.
As a reminder, gossip is the internode communication protocol used by Cassandra.
Nodetool statusthrift, this like gossipinfo does what it says.
It provides thrift information.
Thrift is the low-level API clients communicate with Cassandra over.
Nodetool tpstats, this provide statistics around the number of active,
pending, and completed tasks for each of the Cassandra thread pools.
An example might be large numbers of active threads in the hinted handoff pool,
indicating a connectivity issue in the ring.
And finally, nodetool cfstats,
which provides statistics around keyspaces and column families.
If you run with any arguments,
the command will return statistics for all keyspaces.
Interesting statistics here include read and write latency,
memtable size, size on disk,
and finally, team signs per slice.
If using this command, add minus capital H,
to display more human readable units rather than bytes.
Everything described in this section,
should be used with extreme caution.
Node stop compaction, this stops a compaction event.
You typically perform it if it's been determined that
compaction events are having a negative impact on node performance.
Once compaction has stopped,
Cassandra will continue working through any pending operations in its queue,
and eventually, Cassandra will restart the stopped compaction.
Disable thrift, this prevents a node from acting as a coordinator.
Since the node can still serve read requests,
you would normally also run the next command,
which is disable gossip.
At this point, the node is effectively marked as down in the cluster.
These commands may be used if you're performing maintenance or troubleshooting the node.
The final two commands,
flush memtables to SSTables on disk.
Flush simply flushes the memtables,
whereas drain flushes the memtables but also stops
listening for further client requests until the node is restarted.
Our next open source component is a Apache Zookeeper.
Zookeeper has a number of four-letter codes that can be used to query its reachability,
as well as its current status with respect to its follower,
leader, and observer nodes.
The commands can be invoked using Netcat command, Telnet,
or any other utility that can send commands to a specific TCP port.
The two examples we commonly use are ruok.
Echoing ruok and netcatting it to port 2181 should return the response,
imok, if the service is up and running.
For more information about the Zookeeper's service,
you can use a second command here, stat.
Stat displays a number of statistics around Zookeeper,
some of which are shown here.
We can see in the example that the maximum latency is 26 milliseconds,
there are 470 nodes in the Zookeeper hierarchy,
and the node we've queried is currently a follower.
A full list of the four-letter commands can be found on the link shown.
Our final open source component is Apache Qpid.
There are a number of utilities to interact with Apache Qpid.
All utilities are located in the bin directory underneath the Apigee Qpid directory.
The two most useful commands are described here.
The first is qpid stat minus q.
This shows all configured message queues for Qpid.
Stats include total messages,
messages in, messages out,
as well as a number of bytes.
A more succinct method of sharing similar information is to use the Python script,
check_queue_depth.py, says the name of each analytics queue and so,
is just the queue depth.
You would typically use this to check the queue has been
drained before performing maintenance on the node.
Finally, other components.
The Apigee Edge Operations Guide provides
additional information regarding the management of all Edge components.
The guide includes typical commands,
recurrent activities, and other actions.
The guide can be found on the link provided on the screen.
This concludes Edge Management Infrastructure Operation.
For more information, you can visit docs.apigee.com.
And to get involved in our community,
please go to community.apigee.com. Thank you.