Difference between revisions of "Zenoss Core 5 Beta/Download"
(→Download the Zenoss Docker Images) |
(→Download the Zenoss Docker Images) |
||
Line 115: | Line 115: | ||
<console># serviced deploy-template [SERIVCE_ID] default zenoss </console> | <console># serviced deploy-template [SERIVCE_ID] default zenoss </console> | ||
Finally, make it easy on yourself to find the platform web interface, by adding an alias for the vhost to /etc/hosts. | Finally, make it easy on yourself to find the platform web interface, by adding an alias for the vhost to /etc/hosts. | ||
− | <console> | + | <console># echo $IP zenoss5x.$HOSTNAME >> /etc/hosts</console> |
For example: | For example: | ||
<console> 10.87.120.58 zenoss5x.gee-except </console> | <console> 10.87.120.58 zenoss5x.gee-except </console> |
Revision as of 02:23, 9 May 2014
The Zenoss Core 5 Alpha 2 releases is provided as a virtual appliance. It also supports manual deployment.
This page provides download and deployment instructions for the Zenoss Core Alpha 2.
For more information about the Zenoss Core 5/Europa Alpha 2 release, see Zenoss Core 5 Alpha Technology Overview. For frequently asked questions related to the Zenoss Core 5/Europa Alpha 2 release, see the Zenoss Core 5 Alpha FAQ.
Contents
Packages
The packages for Zenoss Core Alpha 2 can be found on SourceForge, direct links are below:
Core Appliance Deployment
Note: Base VM is preconfigured to use 8GB RAM
- Deploy OVA file via VMware Hypervisor (VM Player, Fusion, Workstation and ESX/ESXi)
- Power on VM and navigate to Control Plane UI per Login details
- Follow verification steps below if you run into any issues with accessing the Control Plane UI
- Follow evaluation steps under the Zenoss Core 5 Alpha/Download#Alpha_2_Feature_Evaluation section
Appliance Login Screen
Login Details
Zenoss Control Plane UI: http://[HOSTIP]:8787 Zenoss Control Plane Log: /var/log/upstart/serviced.log Zenoss App Central Log: http://[HOSTIP]:8787/static/logview/#/dashboard/file/logstash.json SSH & CP User/Password: zenoss
If the control doesn’t startup i.e. is not accessible via your web browser then SSH into the VM and run the following command. In the example above:
- ssh zenoss@192.168.3.150
-
zenoss@zenosscp:~$ sudo /etc/zenosscpreset.sh
- Observe output from script (if need be, you can increase the check timeout beyond 20 seconds, which is hardcoded in the script)
Script timeout configuration in /etc/zenosscopreset.
Control Plane running in a nominal state after startup looks like this:
sudo tail /var/log/upstart/serviced.log
Functioning Control Plane startup
Control Plane Login Screen - http://[HOSTIP]:8787
Once you have verified the control plane UI is up, as shown above. Navigate to the evaluation section.
Manual Deployment
OS Requirements
Ubuntu 12.04
Note: Newer versions of Ubuntu will work but require additional packages/config which are not fully documented.
Hardware Requirements
Minimum 12 GB RAM, 30 GB Disk.
Note: Core can function with 8GB of memory, but will experience memory pressure issues over time.
Installing
Updating the Kernel
install the backported kernel
# sudo apt-get update
serviced requires a 3.8 kernel, confirm using 'uname -a'
install a 3.8 with the following:
# sudo apt-get install linux-image-generic-lts-raring linux-headers-generic-lts-raring # sudo reboot
If you system is running a 3.11 kernel, use the following commands to revert to a 3.8 kernel
remove the 3.11 with the following commands:
# sudo apt-get remove linux-image-3.11.0-15-generic
removing the -15 may install -18, remove it too
# sudo apt-get remove linux-image-3.11.0-18-generic
If you see the following errors:
The link /vmlinuz.old is a damaged link Removing symbolic link vmlinuz.old
you may need to re-run your boot loader[grub]
# sudo update-grub
disable ufw
if the ufw is installed:
# ufw disable
Install Curl, download Docker, LXC and ServiceD
Download and Install Docker:
# sudo apt-get install curl # curl -s https://get.docker.io/ubuntu/ | sudo sh
Install Apparmor and LXC:
# sudo apt-get install apparmor-utils make lxc
Download and Install ServiceD:
# sudo dpkg -i serviced_0.3.70-265_amd64.deb
# sudo apt-get install -f
# sudo start serviced
Download the Zenoss Docker Images
# sudo docker pull quay.io/zenossinc/zenoss5-core:5.0.0_265 # sudo docker pull zenoss/opentsdb:latest
# sudo start serviced
Add your external IP (eth0) as the host IP address.
# IP=`ifconfig eth0 | grep 'inet addr' | cut -d ':' -f 2 | cut -d ' ' -f 1` # serviced add-host $IP:4979 default
Add the Core template, which only appear after installing the control plane package.
# sudo serviced add-template /opt/serviced/templates/zenoss5-core-5.0.0_265.json
Note: If you are using the appliance, the Core template has been modified to support direct port mapping for TCP 8080, under the zproxy service definition.
Deploy the services from the previously added template. SERVICE_ID is the output of the add-template command
# serviced deploy-template [SERIVCE_ID] default zenoss
Finally, make it easy on yourself to find the platform web interface, by adding an alias for the vhost to /etc/hosts.
# echo $IP zenoss5x.$HOSTNAME >> /etc/hosts
For example:
10.87.120.58 zenoss5x.gee-except
Accessing the web UI
Then, to reach the web interface, use the following address:
http://zenoss5x.[HOSTNAME]:8787
To reach the control plane UI, use the following address:
http://[HOSTNAME]:8787
To reach the Zenoss App central log UI, use the following address:
http://[HOSTNAME]:8787/static/logview/#/dashboard/file/logstash.json
Once you have verified the control plane UI is up, as shown above. Navigate to the Zenoss Core 5 Alpha/Download#Alpha_2_Feature_Evaluation.
There is a Control Plane Helper Script (if you have difficulties getting the control plane started)
Alpha 2 Feature Evaluation
If you followed the fresh install instructions, Zenoss is now deployed and ready to go. All you need to do is start the zenoss service, which can be done via serviced or the UI, as described below.
If you downloaded the appliance, follow the instructions below to deploy Zenoss.
Appliance Zenoss Deployment Instructions
- Open up your browser to the Control Plane UI: http://[HOSTIP]:8787
- Enter in your local PAM credentials i.e. User: zenoss Password: zenoss
- Click on Log In button
[[File:image03.png|Control Plane Login Screen - http://[HOSTIP]:8787] - Navigate to Hosts menu
- Click on “Add a Host”
- Add external IP address (see SSH login text for actual external IP) and control plane port: 4979
- Type in “default” for Pool ID
- Click on Deployed Apps
- Click on “Deploy an Application” and follow Deployment Wizard instructions
- Select Deployment ID i.e. development
- Specify Deployment ID i.e. development
- Complete Steps 2 and Steps 3
- Zenoss will now be instantiated in a set of containers, ready to run but will not be running yet (contrary to the UI, Zenoss is not running and will not be listening on localhost:8080).
- Click on the stopped button on the right hand side to start Zenoss (or you can start individual containers if you so choose).
- Click on the Zenoss.core application and you will see individual containers states
- Currently there is no official ‘starting state’ per se aside from an elongated button, thus you should wait around 10-20 seconds for Zenoss to start, depending on the underlying hardware. Note: Zenoss starts most containers in parallel barring certain dependencies, thus startup is significantly faster in comparison to Zenoss 4.X.
- While you are waiting, click on Deploy Apps, Services.
You should see something like:
Service Model Key
Not Running
Application Template Reference
Running Application Container
Assigned Control Plane Host
Note: The Service Model view is available even when an application has not been deployed. In that case, there will be no host reference since the application is ‘scheduled’ to run via a given resource pool/host mapping. Thus only at run time is the host selected.
- Refresh your browser periodically, and once you see everything is green, Zenoss should be ready to use.
- Navigate to the Zenoss Application UI to make sure it is up and running: http://[HOST IP]:8080 OR http://Zenoss5x.[HOSTNAME]:8787
Note: In the case the UI doesn’t come up initially, wait another 10-15 seconds or so. If the UI still doesn’t come up after 30 seconds, login into the appliance via SSH. The login script will detect whether the application is running or not. Also check the Application Central Log interface and search for Zope errors:
http://[HOSTIP]:8787/static/logview/#/dashboard/file/logstash.json
Evaluating Control Plane Features
User Interface
Zenoss Application Log Visualization Dashboard
Zenoss App Central Log: http://[HOSTIP]:8787/static/logview/#/dashboard/file/logstash.json
Zenoss Host Performance & Status
Control Plane Command Line - Service Tree View
- Serviced CLI options: serviced show
- List running services: serviced services
- List templates: serviced templates
- List hosts: serviced hosts
- Remove service: serviced remove-service [serviceguid]
- Remove template: serviced remove-template [templateguid]
- Remove host: serviced remove-host [hostguid]
- Starting serviced: start serviced
- Stopping serviced: stop serviced
- Status serviced: status serviced
- Serviced log: /var/log/upstart/serviced.log
Note: serviced expects GUID references to services, containers, templates and hosts. Please ensure you use the GUID when calling a specific serviced object.
- Docker cheat sheet (assumes root user or sudo rights)
- List running containers: docker ps
- List available images: docker images
- Stop a Docker container: docker stop [containerguid]
- Start a Docker container: docker start [containerguid]
- Forcibly stop a Docker container: docker kill [containerguid]
- Remove a Docker image: docker rmi [imageguid]
Evaluating Zenoss Core New Features
- Open up browser and navigate to http://[HOSTIP]:8080.
Note: If you don’t see Zenoss come up after navigating to the appliance web address, you may need to check a couple of things in the appliance, which is described in the troubleshooting section below.
The following Zenoss setup screen will appear in your browser: - Click on get started and enter in the localhost appliance details in the following screen:
Hostname: [HOSTIP]
Device Type: Linux Server (SSH)
Use the external interface of the local machine or another external target. If you use localhost, nothing will be modeled due to the modeler and ZenCommand processes running within an isolated container.
SSH Credentials
User: zenoss
Password: zenoss - Click on the save button and then skip the rest of the setup
- Enter in ‘localhost’ in the search bar at the top hand corner of the UI
- Click on the localhost link presented by the search bar
- Model the device manually, by clicking on the plus sign at the bottom of the UI and selecting Model Device (unless you want to wait until the next model run)
- The following screen will appear and there should be no errors returned once the model job has completed. If there are errors, review error messages and correct the stated issue(s)
- The following screen will appear and there should be no errors returned once the model job has completed. If there are errors, review error messages and correct the stated issue(s)
{note} If you click on any of the components or graphs, you may see the following error message in the UI.
The error message is OK, it just means the metric tag has not been created yet. The new back-end takes a JIT approach and will create new tags as they are added to the system vs. pre-populating the HBase back-end with a bunch of KPI tags that may never be populated. If you wait a few minutes (polling cycle dependent - default is 5 minutes) you should start to see time series data being rendered in the new graphs, similar to the example below in a few minutes. Data can also be exported to CSV through each graph widget via the cog icon embedded in the title bar:
The underlying JSON data structure can also be viewed by clicking on “Definition”. If you look carefully, you can see where the metric and tag data is stated. This information can be used directly for querying and graphing time series data directly in the TSD interface section below.
Time Zone Support
- Under the user configuration, select your time zone of choice.
- All UI charts will be updated automatically with the new timezone offset.
Refactored Event Class and Transform UI with Syntax highlighting
OpenTSDB Interface
For those who are curious as to how we are leveraging OpenTSDB under the covers, you can take a look at the OpenTSDB UI via http://[HOSTIP]:4242/ or telnet directly into OpenTSDB via telnet [HOSTIP] 4242. The [HOSTIP]:4242 interface will only show metrics collected in the Control Plane. If you want to look at Core/Resource Manager collector metrics, follow these instructions.
- SSH into [HOSTIP]
- Run: sudo docker ps | grep 4242
- Note down the epheremal high port returned i.e. 0.0.0.0:48143->4242/tcp
- Open up your browser to http://[HOSTIP]:[EPort] i.e. http://192.168.3.150:48143 and you should now be able to access the TSD interface in Core/Resource Manager.
The TSD UI has built-in autocomplete, so you can quickly find interesting metrics to graph against.
Try a combination of uppercase and lowercase letters when searching for metrics. For tags, you can use wildcard expressions, thus any metric with one or more tags can be rendered on the same graph. You can even plot different metrics on the same graph across multiple targets. In the future by clicking on the + tab. API documentation will be provided so you can build your own graphs and also be able to import/export data as needed.
Troubleshooting
If the the Zenoss application does not come up on 8080, you may not be using the Appliance or the Vhost configuration. Please follow these instructions:
1. SSH zenoss@[HOSTIP] 2. sudo docker ps -ef | grep 8080 (note down the high port on the left hand side, in the example below it is 49158)
3. Access the Zenoss application through your web browser: http://[HOSTIP]:49158
Logstash Certificate Expired
Note: The X.509 certifcates have expired in the appliance and Debian package.The certificates are required for the central logging feature to function correctly.Please follow instructions below on how to install the new certificates:
- Download logstash-certs.zip
- scp logstash-certs.zip to your alpha 2 deployment
- Unzip logtash-certs.zip to /opt/serviced/isvcs/resources/logstash
- Restart serviced via sudo stop serviced/start serviced or reboot
- Verify Zenoss logs are being indexed by starting Zenoss through the Control Plane and navigate to http://[HOSTIP]:8787/static/logview/#/dashboard/file/logstash.json
Control Plane Helper Script
Control Plane UI is not available or Control Plane doesn’t start properly Use the helper script below to reset Control Plane
#!/bin/sh echo "Stopping serviced" sudo stop serviced # Kill control plane containers echo "Stopping serviced Containers" containers=`sudo docker ps -q` if [ -n "$containers" ]; then sudo docker kill $containers fi # Start serviced echo "Starting serviced" sudo start serviced status serviced echo "serviced started" ZENOSSCPUI=0 ZENCOUNT=0 echo "Zenoss Control Plane is starting up..." sleep 1 while [ "$ZENOSSCPUI" -eq "0" ] && [ "$ZENCOUNT" -lt "20" ]; do sleep 1 ZENCOUNT=$(($ZENCOUNT+1)) ZENOSSCPUI=`netstat -an | grep 8787 | wc -l` done if [ "$ZENOSSCPUI" -eq "0" ]; then echo "Zenoss Control Plane failed to start. Please check /var/log/upstart/serviced.log for errors." sleep 1 else echo "Zenoss Control Plane has started!" sleep 1 fi
If the Control Plane still does not come up, remove and reinstall the Debian package
If you are still having problems, file a defect in jira.zenoss.com with a copy of the serviced.log attached and steps on how to reproduce.
Bugs
We gladly accept bugs as a token of appreciation from our community. The filing process is the same as it is for available Core releases. The main difference is the affected version is code named ‘europa’. If you don’t have a Jira account already, please go ahead and create one, by navigating to jira.zenoss.com. Sign-up link. Once you have created an account, the process is pretty straight forward for filing a bug.
- Click on the Create Issue button on the top of the UI
- Fill out the following fields and attach any relevant screenshots/log files as required
- Please use the defect priority guide below when filing bugs.
Priority | Description |
---|---|
1 | System crash, loss of data, loss of monitoring. This bug will take top priority with development and stop the release of the software until fixed. |
2 | A Feature is not functioning and no workaround exists. Next highest priority for development; will not hold up release. |
3 | A Feature is not functioning a workaround exists |
4 | Lowest severity, minor issues, cosmetic issues. |