OSGi应用中服务组件的在线异常检测方法
PDF格式 | 871KB |
更新于2024-08-26
| 197 浏览量 | 举报
"这篇研究论文探讨了在基于OSGi（Open Service Gateway Initiative）的应用程序中进行面向服务组件的在线异常检测。OSGi是一种流行的框架，用于管理服务导向和组件化应用。由于不同供应商提供的OSGi服务组件通常是黑盒程序单元，缺乏源代码和设计文档，静态代码分析难以评估其质量，缺陷组件可能导致整个系统的失败。因此，论文提出了一种在线方法来检测异常的服务导向组件。"
在基于OSGi的应用程序中，服务组件的异常检测是保障系统稳定性和可靠性的重要任务。由于这些组件通常由不同的供应商提供，且具有封闭性，即不公开源代码和设计细节，这使得传统的静态分析方法无法有效地评估组件的质量。在运行时，如果这些组件出现异常或故障，可能会对整个基于OSGi的应用造成严重影响，甚至导致系统崩溃。
论文中提到的在线异常检测方法旨在解决这一问题。这种方法强调在组件运行过程中实时监测其行为，通过分析组件的服务调用模式、响应时间、资源消耗等动态指标，来识别可能存在的异常情况。这样的在线检测能够及时发现潜在问题，提前采取措施防止故障的发生，从而提高系统的鲁棒性和容错能力。
该方法可能涉及到以下几个关键点：
1. **行为建模**：首先，需要建立正常服务组件的行为模型，这可能是通过对历史数据的学习，理解组件的正常运行模式。
2. **监控与数据收集**：在组件运行时，持续收集关于其操作、性能和交互的数据。
3. **异常检测算法**：利用统计学、机器学习或者人工智能算法，对收集到的数据进行分析，识别出与正常行为模型偏离的异常迹象。
4. **阈值设置**：设定合适的阈值来判断何时的行为变化可以被视为异常，这可能需要根据组件的特性以及业务需求进行调整。
5. **反馈机制**：一旦检测到异常，应有一个快速响应机制，比如报警通知开发者或者自动隔离有问题的组件，以减少影响范围。
这篇研究论文对于理解在复杂分布式环境中的服务组件管理有重要意义，尤其是在OSGi框架下。它提出的在线异常检测策略为实际应用提供了新的思路，有助于提升软件系统的稳定性和安全性。通过这种方式，开发人员可以更好地监控和维护他们的服务组件，降低系统风险，并提高用户体验。
Appl. Math. Inf. Sci. 7, No. ?, 1-12 (2013) / www.naturalspublishing.com/Journals.asp 3
Algorithm 1 Monitoring CPU utilization
Input:
OSGi-based applications;
Output:
CPU utilization for every bundle;
1: if Listen to the event(bundle b is initialized) then
2: Set the bundle ID of thread t as b, and the time stamp for
t ;
3: end if
4: if Listen to the event(thread ts is initialized) then
5: Get the current thread tp which is the parent of ts, and the
bundle ID of tp as bp;
6: Create a new thread ts, and Set the bundleID of ts as bp;
7: end if
8: if Listen to the event(service s
i
invoke service s
j
) then
9: Get the bundle ID of s
i
as b
i
, and the bundle ID of s
j
as
b
j
;
10: if b
i
! = b
j
then
11: Get bundleIn fo
i
of b
i
, and current thread t;
12: Calculate bundleInf o
i
.CPUTime+ =
t.CalculateCPU();
13: Set time stamp for t, and bundle ID of thread t as b
j
;
14: Execute s
j
;
15: Get bundleIn fo
j
of b
j
;
16: Calculate bundleInf o
j
.CPUTime+ =
t.CalculateCPU();
17: Set time stamp for t, and bundle ID of t as b
i
;
18: end if
19: end if
2.1.2 Monitoring static method invocation
Although the OSGi specification recommends developers
to implement the interactions between components with
service invocation, some developers used to invoke the
functions from other components with the traditional
static method invocation. Thus we propose an AOP
(Aspect-Oriented Programming) based method [
10] to
trace the thread transfer between components. The OSGi
framework analyzes the meta data file recording the
exported packages automatically, when a bundle is loaded
dynamically. We extend the original OSGi framework, so
that it reports the exported methods to our monitoring tool
when the analysis is finished. Our tool decides whether
the classes being loaded are exported by the bundle
according to the report. Then, we use AOP to insert the
monitoring points into the beginning and the end of the
public method in the class which exports methods.
We note that some exported packages are not invoked
by other components. The thread transfer does not
happen, when the invoking method and the invoked
method in the same bundle. However, the redundant
monitoring points introduce unnecessary overhead.
Therefore, we use a static code analysis method to reduce
the number of monitoring points before weaving class.
Method invocations usually take the form of
”targetObj.methodName(parameters)”; the key to
analyzing the calling relationship is to know the possible
6HUYLFH3URYLGHU%XQGOH
26*L
6HUYLFH5HJLVWU\
5HJLVWHU
*HQHUDWH
6HUYLFH 6HUYLFH
6HUYLFH3UR[\%XQGOH
63 63
6HUYLFH3URYLGHU%XQGOH
26*L
6HUYLFH5HJLVWU\
5HTXLUH
6HUYLFH
)LQG
6HUYLFH 6HUYLFH
6HUYLFH3UR[\%XQGOH
63 63
6HUYLFH
5HTXHVWHU
5HVSRQG63
,QYRNH63
DZKHQDEXQGOHLVORDGHGDQGDVHUYLFHLVUHJLVWHUHG
EZKHQDVHUYLFHLVUHTXLUHG
,QYRNH6
Fig. 1: Service proxy generation
types of the objects which the targetObj may point to. We
use the class hierarchy analysis method [
11] to gain this
knowledge. All the subtypes of targetObj’s type are
among the possible types, and we can get all the possible
target methods denoted by the methodName. With the
knowledge of the target methods in every invocation
statement, we can easily acquire the calling relationship
between methods, classes, and packages. If two packages
in two different bundles have the calling relationships in
OSGi, the corresponding imported and exported packages
should be specified in the metadata files of the two
bundles. Thus we do not weave the methods invoked in
the same bundle to reduce monitoring overhead.
The object of our AOP based method is to trace the
thread transfer between components, when a component
invokes the others with the static method invocation.
2.2 Monitoring memory utilization of a bundle
The system memory is occupied by objects, which we
will categorize into different bundles. We can also use the
JVMTI to tag every object and calculate its size in
memory. The objects created by different bundles are
tagged with bundle IDs, and thus we calculate the
memory utilization for every bundle. However, how to
distinguish which bundle the objects are subordinate to is
a key problem. With the algorithm 1, we get the relations
between bundles and threads in different periods, and
objects are created by threads. Thus we take the thread as
a bridge between objects and bundles to locate the objects
belonging to different bundles.
In essence, the CPU monitoring and memory
monitoring are both to locate the units in their bundles.
The differences are as follows: 1) the memory utilization
c
2013 NSP
Natural Sciences Publishing Cor.
剩余11页未读，继续阅读
相关推荐
1384 浏览量
39 浏览量
