Survol needs to run one agent per machine: A plain HTTP server running Common Gateway Interface (CGI) Python scripts. This agent and its port number define the identity of each object of this machine, that Survol is able to provide information about. This is the same concept as in WMI and WBEM, and both interoperate completely. Therefore, Survol is able to get information with another machine with no Survol agent: See OpenLMI, WMI etc...

If your browser runs ActiveX, it is also possible to use Survol web pages with no agent.

Survol is based on a tree of Python scripts, all of them display information of the system the agent is running on. Some scripts do not need parameters: They will return information with no context: For example, all available databases, all detected machines on the network, all installed Python modules etc... Other scripts need parameters, as they display information about a specific object. For example; Files opened by a specific process. Columns of a SQL Server
table. Processes connected to an Oracle™ database.

As a benefit of a CGI-based architecture, it is also possible to run any Python scripts as command-line programs. This allows to test them in isolation with full control on ther environment and input, and full visibility on the output. This greatly helps when creating and testing scripts.


Resource Description FrameworkThe internal data model built by Survol, is based on RDF, a standard model for data interchange in the Web. The data representation of Survol is a RDF graph: a set of triples: Subject, relation, object, and is also the core data type found in the Semantic web. It is successfully used in Artificial Intelligence applications. This abstract representation is independent of the display mode. The same set of data, extracted from an information system, is shown several ways:
There are also two output modes, used internally:


To start with, some acronyms. WBEM™ stands for Web-Based Enterprise Managementan industry initiative to develop a standard technology for accessing management information in an enterprise environment. This standard is governed by DMTF, Distributed Management Task Force. WMI is the Microsoft implementation of WBEM. In the Linux world, a common implementation of WBEM is OpenLMI. It is based on an open-source implementation named OpenPegasus™. WBEM standard information is delivered with CIM (Common Information Model).  The CIM schema is the model for delivering this standard information. 

To summarize, WBEM define classes of computer-related objects: Processes, files, network cards etc... have a valid and detailed definition in CIM. Here are some examples:

CIM_Process This is the base class of a process, which is derived into Win32_Process
CIM_Datafile A normal file: The concept and its implementation are similar in Windows and Linux.
CIM_Directory File directories
Win32_UserAccount A Windows user account. Linux has a specific definition, unrelated to this one.


One of the core aspects of Survol is its data model which attempts to take the best of the worlds it is working in. A first approach is WBEM. However, the data description offered by WBEM suffers from several drawbacks:
Despite this, building a software on an industrial standard is invaluably convenient. Therefore, Survol attempts to combine the best of both worlds:


Survol library is made of packages and subpackages which represents its classes model. A class is a module where the function EntityOntology() is present, whether it is defined by the module or one of its parents modules. The return value of EntityOntology() is a list of string, each representing an attribute of the class. If a module nor none of its parent modules define the function EntityOntology(), it is a domain.

A class or a domain can define other functions in its __init__.py file. All of them are optional:

What it does
This returns an array of strings which are the name of the attributes of an object of this class. This does not apply to domains.
This returns a RBG colour coded as a hexadecimal string. This colour is used by any UI mode, for this class/domain, unless it is superseded by a subclass or subdomain.
EntityName This returns a display name for this object, given its attributes passed as an array, in the order specified by the ontology. The hostname is also passed as an argument. The resulting name does have to be unique, but must be printable. This applies to classes only.
AddInfo When displaying an object, adds some extra information related to it.
This tells if the module or the script, is usable in this context, given the platform, available packages etc... It can be defined for any module or any script.

Survol aims to address the diversity of applications running for dozens of years on a variety of architectures. Its framework, based on a tree of Python modules and scripts makes it very easy to add processing to include libraries, architectures, etc.. The concept is the same as adding providers in WBEM and WMI. The inclusion of different architectures in Survol framework, adding a new class, or new scripts, to Survol, is a trivial task: One just need to copy a file tree at a specific place. It is of course possible to mix open-source and proprietary scripts.


Survol is designed to run in a harsh environment, uncertain platforms, broken libraries, incompatible interfaces, and return as much information as possible about unknown applications. It has to be robust and adapt to any situation. Therefore, it is built, at all stages, on the concept of redundancy.

Redundancy of data display:

Survol can display its results in:
Redundancy of information sources:

The core information might come from any source: win32 Python library, any Linux package, WMI and WBEM select statements.

Redundancy of Web hosting:

Scripts can be hosted by Apache, IIS™, the dedicated ad hoc CGI server. Any reasonable HTTP server with CGI or WSGI capabilities should suffice.

Redundancy of Python interpreter and libraries:


Survol scripts access many software resources, some of them being protected with credentials, typically a username and a password. These credentials are made available to Survol with a JSON file, SurvolCredentials.json, residing in the users' home directory. Depending on the user running the HTTP server (Apache, IIS etc...), this home directory may vary. This file can be edited with the "Credentials" page link.

It contains several types of credentials, depending on the type of access: Database software, middleware library etc... For each of this access type, it is possible to add, delete, update any credentials. On the other hand, it is not possible, without extra development, to add new types of credentials as these need specific software to use them.

A typical content of this file might be:

Resource Account Password
Visual Studio Professional 8532-42f4-a66a-c5da7acd
DESKTOP-NI99V8E johnwin
fedora22 mary
sqlusertcsrvdb1.mysql.db sqlusertcsrvdb1
MyOracleDataSource system
XE scott
localhost:12345 guest
SqlExpress\SQLEXPRESS jamessql
WBEM pegasus
http://WIN7-HP:5988 william

It is absolutely mandatory to ensure that this file is protected, for security reasons.

Some subcategories of the credentials file are used for static services discovery:


A Survol setup can run on several machines, each agent providing a facet of the overall multi-hosted application being investigated. To get an overall vision of this application, it is necessary to discover all the Survol agents available, in order to merge their outputs into a single result, whether this result is a SVG document, a HTML page etc...

There are several mechanisms allowing to discover other Survol agents available in the same network.

Return to Survol, or see the FAQs,
use cases, the installation notes, or Doxygen-generated pages here.