Modified items

All recently modified items, latest first.

bcel-6.0-0.5.20140406svn1592769.lbn19.noarch: The Byte Code Engineering Library (formerly known as JavaClass) is intended to give users a convenient possibility to analyze, create, and manipulate (binary) Java class files (those ending with .class). Classes are represented by objects which contain all the symbolic information of the given class: methods, fields and byte code instructions, in particular. Such objects can be read from an existing file, be transformed by a program (e.g. a class loader at run-time) and dumped to a file again. An even more interesting application is the creation of classes from scratch at run-time. The Byte Code Engineering Library (BCEL) may be also useful if you want to learn about the Java Virtual Machine (JVM) and the format of Java .class files. BCEL is already being used successfully in several projects such as compilers, optimizers, obsfuscators and analysis tools, the most popular probably being the Xalan XSLT processor at Apache.

bastion-monit-zenoss4-zep-4.2.5-20.lbn19.noarch: Zenoss Event Processor control script

bastion-monit-zenoss4-mysqld-4.2.5-20.lbn19.noarch: Zenoss MySQL event server start/stop/control

bastion-monit-zenoss4-4.2.5-20.lbn19.noarch: Zenoss start/stop/control

bastion-monit-zenoss-windoz-5.0.5_1.1.2dev-4.lbn19.noarch: Windows monitoring start/stop/control

bastion-monit-zenoss-pythoncollector-5.0.5_1.8.0dev-4.lbn19.noarch: zenpython start/stop/control

bastion-monit-zenoss-ldap-5.0.5_4.0.2-2.lbn19.noarch: zenperfldap start/stop/control

atinject-1-22.20100611svn86.lbn19.noarch: This package specifies a means for obtaining objects in such a way as to maximize reusability, testability and maintainability compared to traditional approaches such as constructors, factories, and service locators (e.g., JNDI). This process, known as dependency injection, is beneficial to most nontrivial applications.

aspectjweaver-1.6.12-8.fc19.noarch: The AspectJ Weaver supports byte-code weaving for aspect-oriented programming (AOP) in java.

args4j-2.33-1.lbn19.noarch: args4j is a small Java class library that makes it easy to parse command line options/arguments in your CUI application. - It makes the command line parsing very easy by using annotations - You can generate the usage screen very easily - You can generate HTML/XML that lists all options for your documentation - Fully supports localization - It is designed to parse javac like options (as opposed to GNU-style where ls -lR is considered to have two options l and R)

apache-mime4j-0.7.2-13.fc24.noarch: Java stream based MIME message parser.

apache-commons-pool-1.6-5.fc19.noarch: The goal of Pool package is it to create and maintain an object (instance) pooling package to be distributed under the ASF license. The package should support a variety of pool implementations, but encourage support of an interface that makes these implementations interchangeable.

apache-commons-cli-1.2-9.fc19.noarch: The CLI library provides a simple and easy to use API for working with the command line arguments and options.

aopalliance-1.0-12.fc24.noarch: Aspect-Oriented Programming (AOP) offers a better solution to many problems than do existing technologies, such as EJB. AOP Alliance intends to facilitate and standardize the use of AOP to enhance existing middleware environments (such as J2EE), or development environements (e.g. Eclipse). The AOP Alliance also aims to ensure interoperability between Java/J2EE AOP implementations to build a larger AOP community.

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).

ZenPacks.zenoss.XenMonitor-4.2.5_1.1.0-1.lbn19.noarch: Xen Monitor --------------------------- XenMonitor is a ZenPack that allows you to monitor virtually hosted operating systems running on a Xen hypervisor. It depends on the prior installation of the ZenossVirtualHostMonitor zenpack. This zenpack: 1) Extends ZenModeler to find Guest OS's and add them to Virtual Hosts 3) Provides templates for collecting resources allocated to Guest OSs. To Use XenMonitor: 1) Ensure that you have SSH keys to your Xen servers (as root). 2) Create your Xen servers using the /Servers/Virtual Hosts/Xen device class. If you have these servers modeled already, remove them and recreate them under the Xen device class. DO NOT MOVE THEM. 3) Select the Guest menu and ensure that the guest hosts were found when the devices were added.

ZenPacks.zenoss.WindowsMonitor-4.2.5_1.1.0-3.lbn19.noarch: This package provides the capability to monitor windows systems. The following daemons perform Windows monitoring tasks: zenwin - monitors Windows service processes zeneventlog - imports events from the Windows Event Log into Zenoss zenwinperf - collects performance information from Windows machines

ZenPacks.zenoss.RabbitMQ-4.2.5_1.0.7-2.lbn19.noarch: To start monitoring your RabbitMQ server you will need to setup SSH access so that your Zenoss collector server will be able to SSH into your RabbitMQ server(s) as a user who has permission to run the rabbitmqctl command. This almost always means the root user. See the Using a Non-Root User section below for instructions on allowing non-root users to run rabbitmqctl. To do this you need to set the following zProperties for the RabbitMQ devices or their device class in Zenoss. * zCommandUsername * zCommandPassword * zKeyPath The zCommandUsername property must be set. To use public key authentication you must verify that the public portion of the key referenced in zKeyPath is installed in the ~/.ssh/authorized_keys file for the appropriate user on the RabbitMQ server. If this key has a passphrase you should set it in the zCommandPassword property. If you'd rather use password authentication than setup keys, simply put the user's password in the zCommandPassword property. You should then add the zenoss.ssh.RabbitMQ modeler plugin to the device, or device class containing your RabbitMQ servers and remodel the device(s). This will automatically find the node, vhosts, exchanges and queues and begin monitoring them immediately for the following metrics. * Node Values o Status - Running or not? Generates event on failure. o Open Connections & Channels o Sent & Received Bytes Rate o Sent & Received Messages Rate o Depth of Send Queue o Consumers o Unacknowledged & Uncommitted Messages * Queue Values o Ready, Unacknowledged & Total Messages o Memory Usage o Consumers There is a default threshold of 1,000,000 messages per queue. This is almost certainly an absurdly high threshold that shouldn't trip in normal systems. However, by clicking into the details of any individual queue you can set the per-queue threshold to a more reasonable value that makes sense for a given queue.

« Previous 20 items Next 20 items » 1 ... 1875 1876 1877 1878 1879 1880 1881 ... 2446


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

Sections

Modified items