Modified items

All recently modified items, latest first.

R-BSgenome.Celegans.UCSC.ce2-1.4.0-5.lbn19.noarch: Caenorhabditis elegans genome grabbed from UCSC (ce2, Mar. 2004) and stored in Biostrings objects

R-BSgenome-1.40.1-1.lbn19.noarch: Infrastructure shared by all the Biostrings-based genome data packages

R-AnnotationDbi-1.34.4-1.lbn19.noarch: Provides user interface and database connection code for annotation data packages using SQLite data storage.

R-ALL-1.6.0-3.lbn19.noarch: Data of T- and B-cell Acute Lymphocytic Leukemia from the Ritz Laboratory at the DFCI (includes Apr 2004 versions)

R-3.3.1-3.lbn19.x86_64: This is a metapackage that provides both core R userspace and all R development components. R is a language and environment for statistical computing and graphics. R is similar to the award-winning S system, which was developed at Bell Laboratories by John Chambers et al. It provides a wide variety of statistical and graphical techniques (linear and nonlinear modelling, statistical tests, time series analysis, classification, clustering, ...). R is designed as a true computer language with control-flow constructions for iteration and alternation, and it allows users to add additional functionality by defining new functions. For computationally intensive tasks, C, C++ and Fortran code can be linked and called at run time.

Dividend: Paying a dividend

periodend_tool: This tool provides process, control, management, and plugins to run end of period processing on BastionLedger's.

General Ledger: General Ledger

portal_bastionledger

openstack-heat-templates-0-0.2.20140407git.lbn19.noarch: Heat example templates and image building elements

openstack-ceilometer-alarm-2015.1.0-7.lbn19.noarch: OpenStack ceilometer provides services to measure and collect metrics from OpenStack components. This package contains the ceilometer alarm notification and evaluation services.

BastionLinux 19: Data science and analytics

Pulp Server: BastionLinux/Pulp Server (software release management) on Amazon Marketplace

BastionLinux 19: Turn your internet gateway into a BastionMonitor and have us remotely monitor your network perimeter. We offer intruder detection, email scanning, traffic reporting, system failure notification and much more.

libconfuse-2.7-5.fc19.x86_64: libConfuse is a configuration file parser library, licensed under the terms of the ISC license, and written in C. It supports sections and (lists of) values (strings, integers, floats, booleans or other sections), as well as some other features (such as single/double-quoted strings, environment variable expansion, functions and nested include statements). It makes it very easy to add configuration file capability to a program using a simple API. The goal of libConfuse is not to be the configuration file parser library with a gazillion of features. Instead, it aims to be easy to use and quick to integrate with your code.

python-signalfx-0.3.9-1.lbn19.noarch: This is a programmatic interface in Python for SignalFx's metadata and ingest APIs. It is meant to provide a base for communicating with SignalFx APIs that can be easily leveraged by scripts and applications to interact with SignalFx or report metric and event data to SignalFx. It is also the base for metric reporters that integrate with common Python-based metric collections tools or libraries. Usage API access token To use this library, you need a SignalFx API access token, which can be obtained from the SignalFx organization you want to report data into. Reporting data Basic usage of the library for reporting data goes as follows: import signalfx sfx = signalfx.SignalFx('MY_TOKEN') sfx.send( gauges=[ {'metric': 'myfunc.time', 'value': 532, 'timestamp': 1442960607000}, ... ], counters=[ {'metric': 'myfunc.calls', 'value': 42, 'timestamp': 1442960607000}, ... ], cumulative_counters=[ {'metric': 'myfunc.calls_cumulative', 'value': 10, 'timestamp': 1442960607000}, ... ]) sfx.stop() The timestamp must be a millisecond precision timestamp; the number of milliseconds elapsed since Epoch. The timestamp field is optional, but strongly recommended. If not specified, it will be set by SignalFx's ingest servers automatically; in this situation, the timestamp of your datapoints will not accurately represent the time of their measurement (network latency, batching, etc. will all impact when those datapoints actually make it to SignalFx). When sending datapoints with multiple calls to send(), it is recommended to re-use the same SignalFx client object for each send() call. If you must use multiple client objects for the same token, which is not recommended, it is important to call stop() after making all send() calls. Each SignalFx client object uses a background thread to send datapoints without blocking the caller. Calling stop() will gracefully flush the thread's send queue and close its TCP connections. Sending multi-dimensional data Reporting dimensions for the data is also optional, and can be accomplished by specifying a dimensions parameter on each datapoint containing a dictionary of string to string key/value pairs representing the dimensions: import signalfx sfx = signalfx.SignalFx('MY_TOKEN') sfx.send( gauges=[ { 'metric': 'myfunc.time', 'value': 532, 'timestamp': 1442960607000, 'dimensions': {'host': 'server1', 'host_ip': '1.2.3.4'} }, ... ], ...) sfx.stop() See examples/generic_usecase.py for a complete code sample showing how to send data to SignalFx. Sending events Events can be sent to SignalFx via the send_event function. The event type must be specified, and dimensions and extra event properties can be supplied as well. import signalfx sfx = signalfx.SignalFx('MY_TOKEN') sfx.send_event( event_type='deployments', dimensions={ 'host': 'myhost', 'service': 'myservice', 'instance': 'myinstance'}, properties={ 'version': '2015.04.29-01'}) See examples/generic_usecase.py for a complete code example. Metric metadata and tags The library includes functions to search, retrieve, and update metric metadata and tags. Deleting tags is also supported. import signalfx sfx = signalfx.SignalFx('MY_TOKEN') sfx.update_tag('tag_name', description='An example tag', custom_properties={'version': 'some_number'}) AWS integration Optionally, the client may be configured to append additional dimensions to all metrics and events sent to SignalFx. One use case for this is to append the AWS unique ID of the current host as an extra dimension. For example, import signalfx from signalfx.aws import AWS_ID_DIMENSION, get_aws_unique_id sfx = signalfx.SignalFx('your_api_token') sfx.add_dimensions({AWS_ID_DIMENSION: get_aws_unique_id()}) sfx.send( gauges=[ { 'metric': 'myfunc.time', 'value': 532, 'timestamp': 1442960607000 'dimensions': {'host': 'server1', 'host_ip': '1.2.3.4'} }, ]) sfx.stop() Pyformance reporter pyformance is a Python library that provides CodaHale-style metrics in a very Pythonic way. We offer a reporter that can report the pyformance metric registry data directly to SignalFx. from pyformance import count_calls, gauge import signalfx.pyformance @count_calls def callme(): pass sfx = signalfx.pyformance.SignalFxReporter(api_token='MY_TOKEN') sfx.start() callme() callme() gauge('test').set_value(42) ... See examples/pyformance_usecase.py for a complete code example using Pyformance.

pyformance-0.3.2-1.lbn19.noarch: Performance metrics, based on Coda Hale's Yammer metrics

ZenPacks.zenoss.Zentrospect-4.2.5_1.2.0-1.lbn19.noarch: Features The features added by this ZenPack can be summarized as follows. They are detailed further below. Discovery of Zenoss systems, processes and metrics thereof. Monitoring of process metric values. Monitoring of process metric freshness. Discovery The following entities will be automatically discovered from server devices that are running Zenoss, have the zenoss.snmp.ZenossSNMP modeler plugin assigned, and have the zenoss-snmp-module extension to Net-SNMP installed and configured properly. Zenoss Systems Attributes: Name Collections: Zenoss Processes, Zenoss Metrics Zenoss Processes Attributes: Name, System Collections: Zenoss Metrics Zenoss Metrics Attributes: Name, System, Process Monitoring The following metrics will be collected every 5 minutes by default. Metrics Metrics: zenProcessMetricValue, zenProcessMetricCyclesSinceUpdate zenProcessMetricValue is the most recent value recorded for the metric. It will be NaN in cases where a value hasn't been recorded recently. zenProcessMetricCyclesSinceUpdate is how many "cycle intervals" it has been since the value was successfully recorded. This measure is used because some metrics are updated on different cycle intervals. For example, if the localhost-zenperfsnmp-devices metric is updated every 300 seconds and was last updated 30 seconds ago, the zenProcessMetricCyclesSinceUpdate value will be 0.1. By default a maximum threshold of 2 is set for zenProcessMetricCyclesSinceUpdate on all discovered metrics. This can be used to identify Zenoss processes that are not functioning properly. Service Impact When combined with the Zenoss Service Dynamics product, this ZenPack adds service impact capability for the entities it discovers. The following service impact relationships are automatically added. These will be included in any services that contain one or more of the explicitly mentioned entities. Service Impact Relationships A Device failure impacts all associated Zenoss Systems. A Zenoss System failure impacts all associated Zenoss Processes. A Zenoss Process failure impacts all associated Zenoss Metrics.

ZenPacks.zenoss.ZenossVirtualHostMonitor-4.2.5_2.4.0-1.lbn19.noarch: Zenoss Virtual Host Monitor --------------------------- ZenossVirtualHostMonitor is a ZenPack that allows you to monitor virtually hosted operating systems. This ZenPack refers to a Virtual Machine Host as the one running on the bare metal, and Guest for those running within the virtual hardware. This zenpack: 1) Extends Devices to support a relationship from Host to Guest. 2) Provides screens displaying resources allocated to Guest OSs. 3) Collects nothing on its own. It provides base functionality for other zenpacks (XenMonitor, VMwareESXMonitor)

ZenPacks.zenoss.ZenJMX-4.2.5_3.9.6-1.lbn19.noarch: ZenJMX is a full-featured JMX client that works "out of the box" with JMX agents that have their remote APIs enabled. It supports authenticated and unauthenticated connections, and it can retrieve single-value attributes, complex-value attributes, and the results of invoking an operation. Operations with parameters are also supported so long as the parameters are primitive types (Strings, booleans, numbers), as well as the object version of primitives (such as java.lang.Integer and java.lang.Float). Multi-value responses from operations (Maps and Lists) are supported, as are primitive responses from operations. The JMX data source installed by ZenJMX allows you to define the connection, authentication, and retrieval information you want to use to retrieve performance information. The IP address is extracted from the parent device, but the port number of the JMX Agent is configurable in each data source. This allows you to operate multiple JMX Agents on a single device and retrieve performance information for each agent separately. This is commonly used on production servers that run multiple applications. Authentication information is also associated with each JMX data source. This offers the most flexibility for site administrators because they can run some JMX agents in an open, unauthenticated fashion and others in a hardened and authenticated fashion. SSL-wrapped connections are supported by the underlying JMX Remote subsystem built into the JDK, but were not tested in the Zenoss labs. As a result, your success with SSL encrypted access to JMX Agents may vary. The data source allows you to define the type of performance information you want to achieve: single-value attribute, complex-value attribute, or operation invocation. To specify the type of retrieval, you must specify an attribute name (and one or more data points) or provide operation information. Any numerical value returned by a JMX agent can be retrieved by Zenoss and graphed and checked against thresholds. Non-numerical values (Strings and complex types) cannot be retrieved and stored by Zenoss. When setting up data points, make sure you understand the semantics of the attribute name and choose the correct Zenoss data point type. Many JMX Agent implementations use inconsistent nomenclature when describing attributes. In some cases the term "Count" refers to an ever-increasing number (a "Counter" data point type). In other cases the term "Count" refers to a snapshot number (a "Gauge" data point type).

« Previous 20 items Next 20 items » 1 ... 1929 1930 1931 1932 1933 1934 1935 ... 2446


	Copyright © 2000-2025 Corporation of Balclutha Inc. All rights reserved.

Sections

Modified items