Blog

  • Monitoring Node Apps on CloudFoundry

    CloudFoundry-1

    There are a few options for monitoring Node applications including NewRelic and NodeTime but I’ll be looking at StrongOps (previously known as NodeFly) by StrongLoop. It’s easy to get up and running with both NewRelic and NodeTime but the StrongLoop offering is particularly easy on CloudFoundry thanks to its custom build pack for deploying applications on Cloudfoundry, more on that later. They also have a lot to offer Node projects in addition to monitoring, check out their website for all the details. StrongLoop also do a lot of work on Node itself so arguably they know more about Node than most.

    Creating an application

    To get started you need an account at StrongLoop and to download their suite. This includes a command line tool slc which includes extra helper commands to get the most out of their offerings including some sample applications. I’ll use a simple instant messaging application to get started.

    slc example chat my-chat
    cd my-chat
    slc install
    node app.js

    The application should start and be available at http://localhost:1337, try opening it in several windows and talking to yourself.

    Monitoring with StrongOps

    Now there is a working application let’s get it running with StrongOps locally before deploying to Cloudfoundry. Create a StrongOps account if you haven’t already and then on the command line use slc to associate the application with StrongOps. Staying in the root of the application.

    slc strongops
    Please enter your: email address:
    Please enter your: password:
    You are now logged in. Welcome back, cgfrost.
    Your StrongOps credentials were written to: ./strongloop.json

    A strongloop.json file will be created in the root of the application that contains all the details needed to talk to the StrongLoop servers. There is an option to use package.json instead if you wish. Running the application again would send monitoring information to the StrongOps console but lets keep going and deploy to Cloudfoundry first.

    Running on Cloudfoundry

    Login in to your favourite Cloudfoundry provider, I’m using Anynines which currently have a free public beta. They are running on Cloudfoundry V2, it is not possible to run StrongOps on Cloudfoundry V1 as V1 doesn’t support custom buildpacks. Buildpacks are originally a concept that Heroku came up with, it is a piece of code that deploys and starts certain application types on a PaaS. It’s through buildpacks that PaaSs like Heroku and Cloudfoundry can support so many different runtimes. To use Anynines the best way to get going if your new to Cloudfoundry is to install their a9s Ruby Gem, see here for details. Once you have an account start by targeting and logging with the cf command line tool.

    cf target https://api.de.a9s.eu
    cf login

    Create a manifest.yml file to tell Cloudfoundry how to deploy the application. The cf command can create an application manifest but some of the config required will be missing. This is the manifest required for the sample chat application.

    ---
    applications:
    - name: chat
      memory: 512M
      instances: 1
      host: chat
      domain: de.a9sapp.eu
      command: node app.js
      buildpack: https://github.com/strongloop/dist-paas-buildpack.git
      path: .

    This manifest contains come common Cloudfoundry config such as memory and the number of instances as well as specifying the start command and buildpack to use. The command configuration should give the same command used to run the application locally, it’s required as Cloudfoundry isn’t able to detect every type of application and this ensures the Node application will actually be started. The buildpack configuration tells Cloudfoundry to explicitly use a buildpack from StrongLoop. This provides the StrongLoop Suite including the same version of Node as you have locally for development as there is no guarantee the version the Cloudfoundry provider has in its Node buildpack will match.

    cf push

    Once the application is pushed, go to your browser and test that the application is running (http://chat.de.a9sapp.eu with the above manifest). Talk to yourself some more to generate some traffic. There should now be traffic reported in the StrongOps console, http://strongloop.com/ops/dashboard. I found there is a minute or two of lag so be patient.

    StrongOpsDashboard

    Have a look around the console to see what metrics are available and try out the memory/CPU profiling. The metrics will be a little limited by the simple sample application but it will give you a good idea of what’s there. There are also some features only available to the paid plans. Happy monitoring.

  • Gemini & Virgo moving on

    GeminiLogoSmallVirgoLogo

    Gemini Management 2.0 has been out for some time and is spec compliant with the OSGi alliance Enterprise 5.0 JMX specification. The project is very much in maintenance mode pending changes to the specification or bugs. I am moving on to new things and while I’m very sad to be leaving behind the wonderful community at Eclipse, Gemini Management will be in good hands. Florian Waibel from Eclipse Source has taken over the leadership and is already getting stuck in to the code with some much needed updates to the build system. I’m still on the mailing lists and I do actually read them as well so I may well pop up in the future but for now I have new challenges to work on.

  • New Web Admin Console In Virgo

    Virgo 3.6.0.M01 has been released and it contains a new web admin console. While visually it appears very similar to the existing web console it has some new features and under the covers a lot has changed.

    New Features

    The OSGi explorer has been replaced with a graphical view that shows both the service and dependency relationships between bundles. Clicking on the relationships or the bundles brings up more detailed information. Double clicking lets you navigate round the bundles and explore their relationships.

    WebAdminBundleWirings

    The Configuration view is now more detailed showing the configuration present in each Region.

    WebAdminConfiguration

    There’s a new view that shows the repositories configured in Virgo and lets you deploy Artefacts directly from those repositories.

    WebAdminRepositories

    Under the Hood

    The Web Admin console now has very few dependencies and can run on either the OSGi HTTPService or as a Web Application Bundle without any changes. It will detect its environment and only deploy itself on a HTTPService if there is no Web Application Container available. It is heavily AJAX based and uses a combination of Gemini Management and Jolokia (a library that converts MBeans to JSON end points) to both read and modify the OSGi framework. The only bundles required in addition are the Equinox Regions implementation, two utility bundles from Apache to handle file uploads and, of course, OSGi itself.

    The best things about these changes is that the Web Admin Console now comes packaged with the Virgo Kernel meaning you get web based admin without needing the full Tomcat or Jetty based packagings of Virgo.

    The Web Admin Console will continue to be developed with more improvements planned.

  • Gemini Management 2.0.0.M01

    GeminiLogoSmall

    Gemini Management is an implementation of the OSGi Enterprise JMX specification. The 2.0.x line moves up to version 5.0 of the specification with several improvements and a new MBean.

    Gemini Management now includes and re-exports the ‘org.osgi.jmx‘ packages from the 5.0 specification meaning you don’t need to separately include the APIs in your runtime. This first milestone hasn’t been checked against the specifications compliance suite yet but it will be before the final release. Some non-spec additions from the 1.0.x releases have been removed from Gemini Management as they have been superseded by new additions to the specification. This mainly affects the bundleState MBean which now allows for listing bundles with only certain information given now being selected by name instead of by an integer mask.

    The main new addition is the new wiringState MBean. It allows the wiring of bundles to be explored including previous revisions of a bundle and the closure of a bundles wiring. In the case of package imports and exports this MBean gives much better information than the packageState MBean.

    Their are two extensions to the serviceState MBean that allows for additional inspections of services based on the bundle registering or consuming the service. They have been found very useful in Virgo and are defined with these two additions to the serviceState Mbean API.

    /**
     * Answer the list of services representing the services this bundle exports
     * 
     * @param bundleId - the bundle identifier
     * @return the list of services
     * @throws IOException if the operation fails
     * @throws IllegalArgumentException if the bundle indicated does not exist
     */
    CompositeData[] getRegisteredServices(long bundleId) throws IOException;
    
    /**
     * Answer the list of services which refer to the the services this bundle is using
     * 
     * @param bundleIdentifier - the bundle identifier
     * @return the list of servics
     * @throws IOException if the operation fails
     * @throws IllegalArgumentException if the bundle indicated does not exist
     */
    CompositeData[] getServicesInUse(long bundleIdentifier) throws IOException;

    Before the final release the code will be run against the 5.0 specifications compliance suite and any bugs fixed. In the mean time the the milestone can be downloaded from the projects Eclipse website here.

  • Gemini Management, soon…

    GeminiLogoSmall

    Gemini Management is a set of JMX MBeans for managing your OSGi runtime. We released the first Milestone last week and will hopefully do a full release in the near future. Gemini Management implements the JMX Specification Version 1.0 of the OSGi Service Platform Enterprise Specification, Version 4.2, section 124. To learn more about Gemini Management you can read the documentation or see the getting started guide on the wiki. The top level Gemini project contains several sub-projects that implement different OSGi enterprise specifications. It has been around a while now but you may still be interested in the original project proposal.

    I’m working to implement changes in the next version of the OSGi Enterprise Specification but I’m more interested in adding support for an OSGi runtime that is split in to multiple areas, such as Subsystems or Regions. This means it has to deal with the possibility of multiple instances of Configuration Admin, bundles that are obfuscated from one another and duplicated bundle names and versions. This is because Virgo makes use of Regions and I’m looking to include Gemini Management in the next release of Virgo. It’ll be another part of Virgo that is standards based which is always a good thing. It’s also part of a bigger plan for a new Admin Console for Virgo, but how to consume MBeans in a browser. Jolokia, a neat project that exports the contents of the MBeanServer over HTTP as JSON data. Even better, it comes packaged as a single OSGi bundle. I think Jolokia and Gemini Management make a great combo and will be powering the new Virgo Admin Console out sometime in 2012.

  • Virgo 3.0 (Maya) RC2

     

    VirgoLogo

    The second Release Candidate of Virgo 3.0 (Maya) is available for download. See the release notes for details.

    RC2 has minor updates from RC1. The documentation has been finished and is now also frozen for release. The version of Equinox has been updated to the stable Indigo version. The separate Snaps download has also moved to RC2 with a much neater download package which includes the Virgo Snaps Guide and a comprehensive sample application along with all the sources.

    RC2 of Virgo Tomcat Server embeds Gemini Web 2.0 RC2 which now comes with documentation in the form of a User Guide plus a minimal Programmer Guide, these are now a part of the download package.

    We encourage users to give RC2 a go and provide feedback via bugzilla or the Virgo forum. Unless critical bugs are found this will be released as 3.0, probably towards the end of August.